Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.arch.embedded Subject: Re: 32 bits time_t and Y2038 issue Date: Sat, 22 Mar 2025 17:57:30 +0100 Organization: A noiseless patient Spider Lines: 61 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 22 Mar 2025 17:57:31 +0100 (CET) Injection-Info: dont-email.me; posting-host="7638945e773161e15f919c68c89e04e1"; logging-data="332903"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19SigCUJzn4RpXzr/Ya90o0X6ESBGzL2Yg=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:L6g5mN1DgMz/iaPkaWrniHF2xJw= In-Reply-To: Content-Language: en-GB Bytes: 3697 On 22/03/2025 15:46, Michael Schwingen wrote: > On 2025-03-22, David Brown 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.