Make.exe for Cygwin

[Ashod Nakashian]

++Norbert

> awesome!

Thanks. The root cause is that stat is not precise enough, not the FS
timestamp precision (I should have redacted that).

>
> that sounds like a reasonable approach for platforms where hi-res stat
> is currently not implemented, i would hope upstream agrees with that.

Indeed. I was doubly surprised when enabling FILE_TIMESTAMP_HI_RES in
config failed to build on Windows at all (no stat with NS fields).
So somebody must've known that Windows has 1s precision stat and
should've deduced this issue.

Also, there is a bug in the supposed workaround for clock skews (when
a file's mtime > systime).

Will see what upstream thinks of both.

>
>> Also, we might merge with 4.1, but that's a different matter.
>>
>> Let me know what you think.
>
> so first i think this whole custom gnu-make-lo needs to die :)
>

I agree with the spirit, but, the built-ins should give a good speed
boost, although I did get some mixed results.

I have patched upstream 4.1, upstream 4.0 (official lo linked,) and
lo-4.0 (lo repo head with my patch), and compared them (with dry-run,
I didn't compare full builds).
With -np: Upstream 4.1 is the fastest (50s,) 4.0 was 58s and lo-4.0 was 61s.
With -n: Upstream 4.1 is the fastest (42s,) 4.0 was 45s and lo-4.0 was 50s.

In theory, the built-in functions should give a healthy speed boost,
but it seems that at least for a dry-run upstream has improved times.

One more tests is necessary to confirm whether the built-ins are
worthwhile or not: apply the LO patch on top of upstream 4.1 and
compare full build times.

>
> last i checked the latest branch in the gnu-make-lo was based on
> upstream 4.0 release; unfortunately that release does not work as a
> Win32 build, it would crash sometimes during the build.

Interesting. I haven't noticed any issues (I had two unit-tests fail,
but restarting the build resumed fine, but I think these are random UT
failures, which do happen from time to time).
How does it crash? Can you give more color?

> if you like you can port the additional debugging options forward from
> the gnu-make-lo-4.0 branch since they are useful, but don't worry about
> the performance hacks.

I'm also curious about the performance hacks. In theory they should
prevent a huge number of process spawns for trivial operations (i.e.
touch).
But upstream 4.1 + debugging options is a good start. Especially that
it seems to offer some speed improvements for a dry run, which might
hint that some unnecessary jobs have been elided, thus making
built-ins less valuable.

I can make binaries available for internal testing purposes.

> once we have some testing for your bug fix you should submit it upstream
> to GNU make.

Sounds good.

Thanks!