[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: misc/54544: Release build options are not public
The following reply was made to PR misc/54544; it has been noted by GNATS.
From: Martin Husemann <martin%duskware.de@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: misc/54544: Release build options are not public
Date: Sat, 14 Sep 2019 14:18:12 +0200
On Sat, Sep 14, 2019 at 02:58:55PM +0300, Andreas Gustafsson wrote:
> Surely you don't mean that the documented procedure for building a
> release should involve extracting the build options from the "base"
> set of the release? That would be a circular defintion, and while it
> could in theory work for reproducing a release that has already been
> made, it wouldn't work for doing advance testing of upcoming releases.
No, I mean: if you have a concrete build result, and want to reproduce that,
it is already possible (though not as trivial as it should).
Also I meant there are not magic or hidden things involved.
> If it's really just those two definitions, how hard could it be to
> make them the default in "build.sh release", or to move them into src
> in some other way?
I am actually in favor of making MKDEBUG=yes the default (I have used
it in all local builds since ages). However, it has a pretty bad build
performance impact if your build machine does not have plenty of RAM
*and* you are building some architecture that requires LLVM parts.
See PR 54136.
The other variation is passing -x to build.sh or not - and the two
architectures where we do not pass -x are the ones where X is not buildable.
Pretty sure this is not worth any changes.
The missing documentation should be added, somewhere - I totally agree with
your intention here.
Main Index |
Thread Index |