Make.exe for Cygwin

[Michael Stahl]

On 24.02.2015 13:50, Ashod Nakashian wrote:
> Michael,
> 
> How can I contribute to the gnu-make-lo repo?

beats me, i've always ignored that repo to the largest extent possible :)

perhaps it's possible via gerrit, if not ask Norbert for direct commit
access.

> I found an issue that I'd like to commit the fix to.
> 
> After tracing for the reason for intermittent failures to generate VS
> IDE files, I found that when invoking make on the same Makefile more
> than once in a row (i.e. when the first make call spawns another
> instance on the same Makefile,) make breaks randomly. The reason is that
> for each run make does "touch Makefile". When this happens in rapid
> succession the second touch doesn't update the modify time (mtime) of
> the file (because it's within the FS timestamp precision, I assume). End
> result is that it thinks touch failed and fails the build.
> 
> The offending logic is in remake.c line 188. I have reproduced the issue
> and confirmed.

awesome!

> The fix is to detect if a file had been modified within the past second
> and delay updating it by up to 1 second. This guarantees that a
> successful update to the file will be detected. This doesn't affect the
> speed in any observable way, as it's only applied when a file is
> updated/touched rapidly. The alternative solution is to implement
> hi-resolution stat on Windows, which is much more effort for hardly any
> gains (over the above solution).

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

> 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 :)

we shouldn't maintain our own make fork but use the upstream release if
possible; the Win32 make binary you can download from
dev-www.libreoffice.org was built from the upstream git repo.

of course thee are some advantages to having this repo, we can do some
experiments and add fixes to bugs we have (like the one you found).

but a lot of the patches that are currently in the repo are just not
something upstream would ever merge anyway (they were a good idea at the
time because they did work around real problems).

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.

so you need to create a new branch; i did test the upstream 4.1 release
and it worked fine for me so you can base it on that.

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.

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