Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.