Re: misc/54544: Release build options are not public

[Martin Husemann <martin%duskware.de@localhost>]

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>
Cc: gnats-bugs%netbsd.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.
 
 Martin