Re: 32 bits time_t and Y2038 issue

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

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.

Depends on your workflow.  I frequently do developement outside
of source tree, then one can forget to copy file to the source
tree.  Explicit list means that you get clear build error when file
is missing, that needs fixing anyway.  Possibly less clear
error when you add file without updating file list, but since
normally adding a file is followed by make it is easy to find
the reason.

 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.

A file is in the project if and only if it is in the source
repository.  Concerning "build", project normally allows
optional/variant files and file is build if and only if it
is needed in choosen configuration.  Clearly, file not needed
in any configuration has no place in source repository.

During developement in my work tree (different from source
repository!) there may be some auxiliary file (it is rather
infrequent and not a big deal anyway, I just mention how
I work).

 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.

Well, for me (as mentioned above) "files in the project" and "build files"
are different things.

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.

Maybe your wildcard use is very simple, but year ago wildcards
were important part in obfuscationg presence of maliciuous code
in lzma.

But more important part is keeping info together, inside Makefile.

--
                              Waldek Hebisch