Re: 32 bits time_t and Y2038 issue

On 21/03/2025 15:04, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 18/03/2025 19:28, Michael Schwingen wrote:

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

>

A good makefile picks up the new files automatically and handles all the
dependencies, so often all you need is a new "make -j".

>
I don't do that anymore - wildcards in makefiles can lead to all kinds of
strange behaviour due to files that are left/placed somewhere but are not
really needed.

>
I'm sure you can guess the correct way to handle that - don't leave
files in the wrong places :-)
>

I prefer to list the files I want compiled - it is not that
much work.
>

>
In a project of over 500 files in 70 directories, it's a lot more work
than using wildcards and not keeping old unneeded files mixed in with
source files.

 In project with about 550 normal source files, 80 headers, 200 test
files, about 1200 generated files spread over 12 directories I use
explicit file lists.  Lists of files increase volume of Makefile-s,
but in my experience extra work to maintain file list is very small.
Compared to effort needed to create a file, adding entry to file list
is negligible.

That's true.
But compared to have a wildcard search to include all .c and .cpp files in the source directories, maintaining file lists is still more than nothing!
However, the real benefit from using automatic file searches like this is two-fold.  One is that you can't get it wrong - you can't forget to add the new file to the list, or remove deleted or renamed files from the list.  The other - bigger - effect is that there is never any doubt about the files in the project.  A file is in the project and build if and only if it is in one of the source directories.  That consistency is very important to me - and to anyone else trying to look at the project.   So any technical help in enforcing that is a good thing in my book.

 Explicit lists are useful if groups of files should get somewhat
different treatment (I have less need for this now, but it was
important in the past).
 

I do sometimes have explicit lists for /directories/ - but not for files.  I often have one branch in the source directory for my own code, and one branch for things like vendor SDKs and third-party code.  I can then use stricter static warnings for my own code, without triggering lots of warnings in external code.

IMO being explicit helps with readablity and make code more
amenable to audit.
 

A simple rule of "all files are in the project" is more amenable to audit.