Re: 32 bits time_t and Y2038 issue

Il 21/03/2025 16:45, David Brown ha scritto:

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.
 

Recetly I included lwip in one of my project. I added it as a git submodule in a subfolder of my repository.
I don't know if you already played with lwip. This repo has several files and directories that aren't strictly needed during build process.
For example, there is test directory that shouldn't be included in the building process of the output binary. So, if you use recursive wildcard (lwip/*), at least you need a facility to exclude a subdirectory (lwip/test).
However this doesn't happen only to subfolders. Consider the folder lwip/src/apps/http. Here you have a simple http client and server implementantion (httpd.c and http_client.c). If you need only the client, you have to exclude httpd.c file from your build.
In this scenario writing explicitly the list of files to compile in the makefile seems a better alternative to wildcard.
Another possibility is to rename or delete the files/folders you don't need under lwip folder. However this means you will not have a clean copy of the lwip official repository.