Hi, is there any way to "enforce" a CubeIDE version in code, e.g. a static_assert()? Regards, Goran

[waclawek.jan]

Why would you want to enforce the *IDE* version? Don't you want to check the Cube i.e. "library" - or, as ST calls it, "firmware" or "driver" - version?

For that, see HAL_GetHalVersion() function - it returns a constant defined for each variant of Cube individually, e.g. for CubeF1 it's __STM32F1xx_HAL_VERSION.

Unfortunately, as it's defined in .c, I don't know how to check that compile-time.

JW

[Pavel A.]

.

[Piranha]

Just think about how "competent" the developers have to be to not understand that those trivial macros are defined in the wrong place! Then imagine them writing a complex asynchronous code with interrupts and threads for a superscalar CPU with a cache memory...

[mattias norlander]

Hi @GoEk​ ,

There is code freeze and there is tool freeze. In this thread so far people are talking about code freeze.

Do you really need to freeze on an IDE version or do you only need to freeze which GCC version that is used?

For the GCC version :

#define GCC_VERSION (__GNUC__ * 10000 \
                               + __GNUC_MINOR__ * 100 \
                               + __GNUC_PATCHLEVEL__)
 
#if GCC_VERSION != 100301
	#error "Incorrect GCC version used"
#endif

Will add a ticket for your feedback @Community member​​, related to location of symbols in c-files. Does not make sense.

[GoEk]

For clarification, this is to maintain tool version coherence within a team. Why? I have had an experience where opening a project in an IDE of an older version than the project was last used by corrupted the project. So, this is more of a tool issue.

How do you maintain tool version discipline within a team?

[GoEk]

This is primarily an IDE issue, so everyone in the team uses the same version to prevent project corruption. Secondarily, so everyone uses the same toolchain versions.

[KnarfB]

If a tool (actively) changes or corrupts code, the (passive) code cannot protect itself from being corrupted. You surely use git or another source version control software. You might want setup a dedicated build server doing automated nightly builds using a well defined toolset. Maybe combined with jenkins or gitlab continuos integration pipelines.

hth

KnarfB

[GoEk]

No code was altered, it broke the CubeIDE project settings/file. CubeMX has a project file version check but CubeIDE seems to not have it so my main worry is having team members using different versions of CubeIDE and break the IDE project file.

[Pavel A. · Accepted solution]

> it broke the CubeIDE project settings/file

The CubeIDE project files are .project, ,cproject and optionally the .ioc.

From our experience, these files are stable and work after updating CubeIDE

(though not compatible across different Eclipse CDT based products).

The Eclipse "metadata" in .settings dir is much less stable, from our experience it should not be checked in, even though it is tempting to do so. Same for the .mxproject Cube files.

After every CubeIDE update, we rebuild the workspace from scratch and re-import all projects.

> How do you maintain tool version discipline within a team?

We record all tools and libraries versions. We also have copies of required downloads.

Everyone may use what they like - as long as it does not break build or cause problems to others. Else there are obvious consequences.