Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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: <vrmq5q$a537$2@dont-email.me>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
 <slrnvtbaot.sal.news-1513678000@a-tuin.ms.intern>
 <vrbado$2133a$1@dont-email.me> <vrbi79$2a30t$1@dont-email.me>
 <slrnvtjeq9.566.news-1513678000@a-tuin.ms.intern>
 <vrcidh$35fbp$2@dont-email.me> <vrjrm9$2ehre$1@paganini.bofh.team>
 <vrk1i7$1qjnk$1@dont-email.me> <m469dhFcgv5U1@mid.dfncis.de>
 <vrme0b$22h9$1@dont-email.me>
 <slrnvttj9v.566.news-1513678000@a-tuin.ms.intern>
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: <slrnvttj9v.566.news-1513678000@a-tuin.ms.intern>
Content-Language: en-GB
Bytes: 3697

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.