Skip to main content
Jim Seymour
Senior
May 13, 2026
Question

Is it possible in STM32CubeIDE to set a compiler dependency on ALL sources?

  • May 13, 2026
  • 5 replies
  • 231 views

I am using the latest STM32CubeIDE on a Windows platform - developing code for a STM32G0B1.

I have a version.c file in my project that uses the __DATE__ and __TIME__ macros to create strings that I use in other modules.

To ensure this file gets compiled on every build, I have a custom Pre-Build step that "touches" that file.  This all works fine.

However, if I use the IDE to load the code into my hardware, it always does a build beforehand.  Because of this "touch", I get a new date string every time I run a debug session.

Is it possible to replace the "touch" step with some kind of dependency on "all source files"?  In other words, can I make it so my version.c gets recompiled ONLY if some other source file has been updated?

I know that I can turn off the "Build (if required) before launching" option.  But I'd rather keep that option as is, unless  changing it is the only way to do what I want.

Thanks.

 

 

5 replies

Pavel A.
Super User
May 14, 2026

AFAIK Eclipse CDT (managed builder) does not allow this easily.

You can add pre-build step that runs make with a little makefile: a target that depends on all your C files and the action executes touch version.c.

But the question is how to get the list of "all C files" from that makefile. You can simply glob *.c or manually write the list. Both ways are far from elegance.

 

 

Andrew Neil
Super User
May 14, 2026

Keil uVision used to have this feature (back in C51 days) - indeed, I found it useful for this very task:

You could set an 'Always Build' option on a file - meaning that the file would be built if and only if any other files needed building.

ISTR last time I tried it (on ARM MDK), that was broken, and the operation had become just, "build every time, irrespective of whether anything else needs building"

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Jim Seymour
Senior
May 14, 2026

Thanks!  I'll do some experiments with the "Always Build" option (though I suspect that Andrew is right).

Meanwhile, the "make" option sounds promising.  Does STM32CubeIDE have a make utility included or should I find one elsewhere.  (I've got cygwin, if need be - but that seems problematic if I have to move this project to another computer).

 

 

Andrew Neil
Super User
May 14, 2026

@Jim Seymour wrote:

Thanks!  I'll do some experiments with the "Always Build" option


for the avoidance of doubt, that option was on Keil - not CubeIDE

 


@Jim Seymour wrote:

Does STM32CubeIDE have a make utility included

 


Yes, it creates its own makefiles from the project - you can see them in build output folders:

AndrewNeil_1-1778779263639.png

 

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Jim Seymour
Senior
May 14, 2026

Ah, yes.  I misread your earlier post.  Thanks.

 

Pavel A.
Super User
May 14, 2026

Because this feature is unusual and depends on the build tools/vendor/IDE, I'd prefer a different approach.

Instead of checking "all other dependencies", which the build tool does anyway, check if the build artifact changes by the last build. Then update the version file. Then make again or let Eclipse to auto-build before debugging. This check can run as the post-build step. This is simple and works with all decent IDEs that have post-build step, but the downside is repeated build.

A more complicated way is to separate the version-dependent data and make them a "resource", in Windows or Apple sense. This requires additional build step that produces "binary with resources". The latter artifact becomes the final build target:

* If the dependencies of "resources" change, the resources are updated.

* If C/C++ source files change - the executable is built

* If anything of above changes, the final artifact is updated (for example, by some tool that merges or patches binaries).

This is of course more complicated, but avoids double build.

For the simple way, the post build script can be like this:

if current-binary does NOT exist OR (version.c is older than current-binary) :
 touch version.c
endif

 

Jim Seymour
Senior
May 14, 2026

I think the makefile solution is the right answer (at least for me).

Here's what I did:

My Pre-Build step is now "make -C ../Core/Src -f version.mk"

And my version.mk file contains one rule:

version.c: *.c ../Inc/*.h
	touch version.c

Because I use *.c in the rule, it produces a warning: "Circular version.c <- version.c dependency dropped"

But that's mostly harmless and allows me to add or remove source/include files without having to modify the makefile.

All works well (so far).

Thanks again for the help!

One remaining mystery: I'm not sure where 'touch' comes from.  If that's built in to the IDE, then it's all good.  But it might be picking that up from cygwin or somewhere else on my PC.  To make this more portable, I might need to change that to some kind of "copy /b" command using the Windows command line.

 

Pavel A.
Super User
May 14, 2026
SRCS := $(filter-out version.c, $(wildcard *.c))

version.c: $(SRCS) ../Inc/*.h
	touch version.c

Touch comes from the CubeIDE, as does the make. CubeIDE installs busybox that implements touch and many other commands used in makefiles. No cygwin is needed.

Andrew Neil
Super User
May 18, 2026

Just thinking aloud here:

I guess you could do some sort of hash of all the source code?

This wouldn't stop the version.c file getting rebuilt every time, but it would let you see whether the rest of the code actually changed or not.

Or you could take it further: save the hash in a file somewhere, and only do the touch when the hash has changed?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.