Re: 32 bits time_t and Y2038 issue

On 22/03/2025 15:46, Michael Schwingen wrote:

On 2025-03-22, David Brown <david.brown@hesbynett.no> wrote:

>
If I have a project, the files in the project are in the project
directory.  Where else would they be?  And what other files would I have
in the project directory than project files?

 If the project can be compiled for different targets, you may have files
that are used only for one target - stuff like i2c_stm32f0.c and
i2c_stm32f1.c.
 Both are project files, but only one is supposed to end up in the
compilation.  You may work around this by putting files in separate
directories, but at some point you end up with lots of directories with only
1 file.

That is a possibility, yes - and I have had such cases and dealt with them by including or excluding specific directories.  You are very unlikely to have /lots/ of directories with only one file, because your one project does not usually need lots of builds.  And you also often have multiple device-specific files, not just one - especially for significantly different devices.
It is also not uncommon to see headers done like this :
// device.h
#if DEVICE == DEVICE_STM32F0
   #include "device_stm32f0.h"
#elif DEVICE == DEVICE_STM32F1
   #include "device_stm32f1.h"
#endif
That's less common for C or C++ files than for headers.

 This gets to the point of build configuration - make needs to know which
files belong to a build configuration.  Putting "#ifdef TARGET_STM32F0"
around the whole C file is not a good way to do this in a larger project
(not only because newer compilers complain that "ISO C forbids an empty
translation unit").

Add :
enum { this_file_may_be_intentionally_blank };
:-)

 Some optional features influence both make and the compile progress - at
work, we decided to put that knowledge outside make, and generate sets of
matching include files for make/c/c++ during the configure stage.
 As you said, there are pros and cons - use what works for your project.
 

Indeed.  But I find wildcard identification of files for the build to be many more pros, and fewer cons, than explicit lists - at least as the normal pattern.