Re: 32 bits time_t and Y2038 issue

Am 21.03.2025 um 16:45 schrieb David Brown:

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

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

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.

[...]
This argument blindly assumes files matching the wildcard patterns must self-evidently be "old", and "still" in there.  That assumption can be _wildly_ wrong.  People will sometimes make backup copies of source files in situ, e.g. for experimentation.  Source files can also get accidentally lost or moved.
Adding a source to the build on the sole justification that it exists, in a given place, IMHO undermines any remotely sane level of configuration management.  Skipping a file simply because it's been lost is even worse.
Hunting for what source file the undefined reference in the final link was supposed to have come from, but didn't, is rather less fun than a clear message from Make that it cannot build foo.o because its source is nowhere to be found.  The opposite job of hunting down duplicate definitions introduced by spare source files might be easier --- but then again, it might not be.  Do you _always_ know, off the top of your head, whether the definition of function "get_bar" was supposed to be in dir1/dir2/baz.cpp or dir3/dir4/dir5/baz.cpp?

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!

Which IMHO actually is the best argument _not_ to do it every time you run the build.  And that includes not having make to do it for you, every time.  All that wildcard discovery adds work to every build while introducing unnecessary risk to the build's reproducibility.
Setting up file lists using wildcards is a type of job best done just once, so after you've verified and fine-tuned the result, you save it and only repeat the procedure on massive additions or structural changes.
Keeping that list updated will also be less of a chore than enforcing a "thou shalt not put files in that folder lest they will be added to the build without your consent" policy.