svn commit: r251652 - head/release

[Glen Barber]

On Wed, Jun 12, 2013 at 11:42:24PM +0900, Hiroki Sato wrote:
> nw> On 06/12/13 09:12, Glen Barber wrote:
> nw> > On Wed, Jun 12, 2013 at 11:08:00PM +0900, Hiroki Sato wrote:
> nw> >> gj> Author: gjb
> nw> >> gj> Date: Wed Jun 12 13:15:28 2013
> nw> >> gj> New Revision: 251652
> nw> >> gj> URL: http://svnweb.freebsd.org/changeset/base/251652
> nw> >> gj>
> nw> >> gj> Log:
> nw> >> gj> Add new script to run release builds.  The script is heavily based
> nw> >> upon
> nw> >> gj>   the release/generate-release.sh script by nwhitehorn.
> nw> >> gj>
> nw> >> gj> This script can use optional configuration file to override
> nw> >> defaults,
> nw> >> gj> making running multiple serialzied builds with different specific
> nw> >> gj>   configurations or architecture-specific tunings quite easy.
> nw> >> gj>
> nw> >> gj> Sample overrideable options are included in the
> nw> >> release.conf.sample
> nw> >> gj>   file.
> nw> >> gj>
> nw> >> gj>   Approved by:	kib (mentor)
> nw> >> gj>   MFC After:	2 weeks
> nw> >> gj>   X-MFC-To:	stable/9 only
> nw> >>
> nw> >>   Are you planning to replace generate-release.sh with this or keep the
> nw> >>   two scripts?
> nw> >>
> nw> > The plan is to eventually replace the generate-release.sh script.
> nw> >
> nw> > Glen
> nw> >
> nw>
> nw> As I mentioned in a private email to Glen, it might be reasonable just
> nw> to replace it now. generate-release.sh exists solely for the
> nw> convenience of re@ (the main tool is just make release) and so we
> nw> should just have whichever tools re@ finds more convenient. I suspect
> nw> it is the new script.
> 
>  I agree.  Maintaining two scripts are confusing.
> 
>  However, I do not think the imported version of release.sh is ready
>  because it has non-reasonable default values like
>  TARGET_ARCH=${TARGET}, for example.  When this script was submitted
>  by Glen a while ago, I did not merge parts which were problematic or
>  difficult to maintain.
> 

In cases such as amd64 and i386, TARGET and TARGET_ARCH are set to the
same value.

For architectures like pc98, mips, etc., they surely will differ.
However, IMHO, for these cases, that is where reading in a configuration
file makes things much easier to tune per-build, rather than setting
environment values.

When I originally proposed these changes, buildworld with empty
TARGET/TARGET_ARCH would cause the build to fail.  I would need to find
the thread in my email archives to remember specifically where it was
broken.

I can rework it so TARGET and TARGET_ARCH are only included in make(1)
arguments if set if that is desired.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130612/8b7690a8/attachment.sig>