Re: 32 bits time_t and Y2038 issue

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

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

Install msys2 (and the mingw-64 version of gcc, if you want a native
compiler too).  Make sure the relevant "bin" directory is on your path.
Then gnu make will work perfectly, along with all the little *nix
utilities such as touch, cp, mv, sed, etc., that makefiles sometimes use.
>
The only time I have seen problems with makefiles on Windows is when
using ancient partial make implementations, such as from Borland, along
with more advanced modern makefiles, or when someone mistakenly uses
MS's not-make "nmake" program instead of "make".

 I have seen problems when using tools that are build during the compile
proess, used to generate further C code.

I have several projects where C code is generated automatically (such as with a Python script that turns an image file into a const uint8_t array).
In the days of FAT filesystems - 16-bit Windows and DOS, primarily - it was possible to get issues with that kind of thing along with the weaker "make" implementations included with Borland tools and the like.  The big issue was the timestamp resolution for files was too coarse.

 I would suggest using WSL instead of msys2. I have not used it for
cross-compiling, but it works fine (except for file access performance) for
my documentation process, which needs commandline pdf modification tools
plus latex.
 

I would not suggest WSL unless you are trying to re-create a full Linux environment - since that is what WSL is.  It is a virtual machine with Linux.  If you have a complex setup with *nix features like soft links, or filenames with Windows-hostile characters, or want to use /dev/urandom to generate random data automatically in your build process, then use WSL.  (Or just switch to Linux.)
msys2 is totally different.  The binaries are all native Windows binaries, and they all work within the same Windows environment as everything else.  There are no problems using Windows-style paths (though of course it is best to use relative paths and forward slashes in your makefiles, #include directives, etc., for cross-platform compatibility).  You can use the msys2 programs directly from the normal Windows command window, or Powershell, or in batch files, or directly from other Windows programs.
I have also used pdf modification tools and pdfLaTeX (Miktex) on Windows, controlled by make, from msys.  (It's been a while, so it was probably msys make rather than msys2 make.)
I do most of that kind of thing from Linux - amongst other things, it is faster on the same hardware for all of this stuff.  But I like my builds to work on Windows as well as Linux.

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.