
On 05/14/16 10:18 PM, Páli Gábor János wrote:
2016-05-14 13:06 GMT+02:00 Karel Gardas
: On 05/14/16 11:28 AM, Ben Gamari wrote:
The pragmatist in me wants to answer 1) yes, 2) no, although I do dislike the idea of distributing binaries that weren't derived from the associated source tarball.
I guess all other Linuxes naturally use gnu make as `make' and Windows in msys too so only non-GNU/non-Linux systems should be affected and from those only FreeBSD has caught this.
Yes, that is possible. I do not know either Solaris or OpenBSD well enough, but I suspect they might have GNU make(1) installed in their paths as `make` or their default make(1) can understand GNU-style
No, on Solaris `make` is some Sun/Oracle make: $ make --version make: Warning: Ignoring DistributedMake -v option make: Warning: Ignoring DistributedMake -o option make: Fatal error: No dmake output dir argument after -o flag and GNU make is correctly installed as `gmake`: $ gmake --version GNU Make 3.82 Built for i386-pc-solaris2.11 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. and on OpenBSD this is the same, except that `make` is BSD make: $ make --version make: unknown option -- - usage: make [-BeiknpqrSst] [-C directory] [-D variable] [-d flags] [-f mk] [-I directory] [-j max_processes] [-m directory] [-V variable] [NAME=value] [target ...] $ gmake --version GNU Make 4.1 Built for x86_64-unknown-openbsd5.9 Copyright (C) 1988-2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Anyhow, in my humble opinion, it is a bad practice the hardwire the name of the make tool in the sources.
Completely agree with you on this.
If this is true, then I would recommend "no" to both points and leave the fix in 8.0 branch for 8.0.2...
Well, in theory, FreeBSD is still a Tier-1 platform, so every release should just build fine without any further efforts. I am also aware of the fact I am considered a minority here, and that this is just a minor technical problem that could wait for some undetermined time. However, personally, I would be quite disappointed if this promise was broken.
Hmm, indeed, FreeBSD is tier-1. I'm sorry, but I completely forgotten this.
I am sorry and apologize that I found this bug after the release was tagged, but I did not have the chance to test it before it was considered a final release. I tracked the 8.0.1 Release Candidates and provided binary tarballs for them, they all went fine, but apparently that was not enough.
Apparently this slipped from HEAD to 8.0 branch and it should not, especially considering this was already on RC4. But well such mistakes happen. OK! I've thought to save the energy on building another set of dists, but you have my word on this, to have FBSD folks happy I'm ready to rebuild again if Ben submits `c' version of 8.0.1 release source code. :-) Cheers, Karel