MAKEFLAGS and build.sh

[Mikko Rapeli-4]

    Allow user to define MAKEFLAGS through build.sh. It's nice when a
    MAKEFLAGS=-k is needed to keep going and log all failing objects
    in one run.

diff --git a/build.sh b/build.sh
index 026e5b2..cefa19b 100755
--- a/build.sh
+++ b/build.sh
@@ -202,7 +202,7 @@ initdefaults()
  MAKEFLAGS=-X
  ;;
  *)
- MAKEFLAGS=
+ MAKEFLAGS=$MAKEFLAGS
  ;;
  esac
 

[Luke Mewburn]

On Fri, Aug 15, 2008 at 11:39:06AM +0300, Mikko Rapeli wrote:
  |
  |     Allow user to define MAKEFLAGS through build.sh. It's nice when a
  |     MAKEFLAGS=-k is needed to keep going and log all failing objects
  |     in one run.
  |
  | diff --git a/build.sh b/build.sh
  | index 026e5b2..cefa19b 100755
  | --- a/build.sh
  | +++ b/build.sh
  | @@ -202,7 +202,7 @@ initdefaults()
  |   MAKEFLAGS=-X
  |   ;;
  |   *)
  | - MAKEFLAGS=
  | + MAKEFLAGS=$MAKEFLAGS
  |   ;;
  |   esac
  |  


I don't think we should pass arbitrary MAKEFLAGS through build.sh,
since certain settings are set internally, and I'm concerned
that MAKEFLAGS set in the environment could cause difficult to
diagnose failures.

That doesn't prevent us considering a separate build.sh control
to explicitly enable the "make -k" behaviour that you desire.

I would have suggested "build.sh -k", but that flag is already
used (to warn about deprecated behaviour).  I am going to
remove the deprecated warnings for -b, -d, -i, -k, -t, since
the "new way" for those operations has been in place since
before NetBSD 2.0.  Then we might be able to use -k in build.sh
for the purpose.


Luke.

[Mikko Rapeli-4]

On Sat, Aug 23, 2008 at 08:19:01AM +1000, Luke Mewburn wrote:
> On Fri, Aug 15, 2008 at 11:39:06AM +0300, Mikko Rapeli wrote:
>   |
>   |     Allow user to define MAKEFLAGS through build.sh. It's nice when a

                        ^^^^^^ initialize is a better word for it

>   |     MAKEFLAGS=-k is needed to keep going and log all failing objects
>   |     in one run.
>   |
>   | diff --git a/build.sh b/build.sh
>   | index 026e5b2..cefa19b 100755
>   | --- a/build.sh
>   | +++ b/build.sh
>   | @@ -202,7 +202,7 @@ initdefaults()
>   |   MAKEFLAGS=-X
>   |   ;;
>   |   *)
>   | - MAKEFLAGS=
>   | + MAKEFLAGS=$MAKEFLAGS
>   |   ;;
>   |   esac
>   |  
>
>
> I don't think we should pass arbitrary MAKEFLAGS through build.sh,
> since certain settings are set internally, and I'm concerned
> that MAKEFLAGS set in the environment could cause difficult to
> diagnose failures.

Ok, my patch only allows user to initialize MAKEFLAGS. Lots of
things are added to MAKEFLAGS past that point in the code. It is not
just cleared on invocation but set initially to the value of a user
defined MAKEFLAGS, which defaults to nothing. Here's a second attempt.

> That doesn't prevent us considering a separate build.sh control
> to explicitly enable the "make -k" behaviour that you desire.

Well, I don't use -k too often, so I think a flag in build.sh would be
overkill. Allowing a user with knowledge to set inital MAKEFLAGS would
be better. Setting CPUFLAGS, CFLAGS, LDFLAGS etc. have no problems with
build.sh so I thought MAKEFLAGS would be similar, at least in the
trivial case of adding a -k.

-Mikko

diff --git a/build.sh b/build.sh
index cefa19b..d1cd89e 100755
--- a/build.sh
+++ b/build.sh
@@ -197,12 +197,14 @@ initdefaults()
  # Some systems have a small ARG_MAX.  -X prevents make(1) from
  # exporting variables in the environment redundantly.
  #
+ # Allow user to provide initial MAKEFLAGS.
+ #
  case "${uname_s}" in
  Darwin | FreeBSD | CYGWIN*)
- MAKEFLAGS=-X
+ MAKEFLAGS="${MAKEFLAGS} -X"
  ;;
  *)
- MAKEFLAGS=$MAKEFLAGS
+ MAKEFLAGS=${MAKEFLAGS}
  ;;
  esac
 

[Alan Barrett]

On Mon, 25 Aug 2008, Mikko Rapeli wrote:

> On Sat, Aug 23, 2008 at 08:19:01AM +1000, Luke Mewburn wrote:
> > I don't think we should pass arbitrary MAKEFLAGS through build.sh,
> > since certain settings are set internally, and I'm concerned
> > that MAKEFLAGS set in the environment could cause difficult to
> > diagnose failures.
>
> Ok, my patch only allows user to initialize MAKEFLAGS. Lots of
> things are added to MAKEFLAGS past that point in the code. It is not
> just cleared on invocation but set initially to the value of a user
> defined MAKEFLAGS, which defaults to nothing. Here's a second attempt.
>
> > That doesn't prevent us considering a separate build.sh control
> > to explicitly enable the "make -k" behaviour that you desire.

At present, build.sh ignores any MAKEFLAGS passed in the environment,
and also ignores any MAKEFLAGS set via "-V MAKEFLAGS=value".  The
appended patch makes build.sh ignore any MAKEFLAGS passed in the
environment (as at present), but makes it accept "-V MAKEFLAGS=value".
Does this address everybody's concerns?

--apb (Alan Barrett)

[Alan Barrett]

On Tue, 14 Oct 2008, Alan Barrett wrote:
> At present, build.sh ignores any MAKEFLAGS passed in the environment,
> and also ignores any MAKEFLAGS set via "-V MAKEFLAGS=value".  The
> appended patch makes build.sh ignore any MAKEFLAGS passed in the
> environment (as at present), but makes it accept "-V MAKEFLAGS=value".
> Does this address everybody's concerns?

Sorry, with the patch this time.

--apb (Alan Barrett)

Index: build.sh
===================================================================
--- build.sh 22 Aug 2008 23:41:24 -0000 1.197
+++ build.sh 14 Oct 2008 21:19:42 -0000
@@ -162,6 +162,17 @@
  [ -f share/mk/bsd.own.mk ] ||
     bomb "src/share/mk is missing; please re-fetch the source tree"
 
+ # Set various environment variables to known defaults,
+ # to minimize (cross-)build problems observed "in the field".
+ #
+ # These variables can be overridden via "-V var=value" if
+ # you know what you are doing.
+ #
+ unsetmakeenv INFODIR
+ unsetmakeenv LESSCHARSET
+ setmakeenv LC_ALL C
+ unsetmakeenv MAKEFLAGS
+
  # Find information about the build platform.  Note that "uname -p"
  # is not part of POSIX, but NetBSD's uname -p prints MACHINE_ARCH,
  # while uname -m prints MACHINE.
@@ -199,10 +210,7 @@
  #
  case "${uname_s}" in
  Darwin | FreeBSD | CYGWIN*)
- MAKEFLAGS=-X
- ;;
- *)
- MAKEFLAGS=
+ MAKEFLAGS="-X ${MAKEFLAGS}"
  ;;
  esac
 
@@ -258,13 +266,6 @@
  # Set the BUILDSEED to NetBSD-"N"
  #
  setmakeenv BUILDSEED "NetBSD-$(${HOST_SH} ${TOP}/sys/conf/osrelease.sh -m)"
-
- # Set various environment variables to known defaults,
- # to minimize (cross-)build problems observed "in the field".
- #
- unsetmakeenv INFODIR
- unsetmakeenv LESSCHARSET
- setmakeenv LC_ALL C
 }
 
 getarch()
Index: BUILDING
===================================================================
--- BUILDING 24 Sep 2008 07:38:04 -0000 1.78
+++ BUILDING 14 Oct 2008 21:19:43 -0000
@@ -104,7 +104,9 @@
 
      MAKE              Path name to invoke make(1) as.
 
-     MAKEFLAGS         Flags to invoke make(1) with.
+     MAKEFLAGS         Flags to invoke make(1) with.  Note that build.sh
+                       ignores the value of MAKEFLAGS passed in the environ-
+                       ment, but allows MAKEFLAGS to be set via the -V option.
 
      MAKEOBJDIR        Directory to use as the .OBJDIR for the current direc-
                        tory.  The value is subjected to variable expansion by
Index: doc/BUILDING.mdoc
===================================================================
--- doc/BUILDING.mdoc 24 Sep 2008 07:36:52 -0000 1.67
+++ doc/BUILDING.mdoc 14 Oct 2008 21:19:45 -0000
@@ -213,6 +213,15 @@
 Flags to invoke
 .Xr make 1
 with.
+Note that
+.Sy build.sh
+ignores the value of
+.Sy MAKEFLAGS
+passed in the environment, but allows
+.Sy MAKEFLAGS
+to be set via the
+.Fl V
+option.
 .
 .It Sy MAKEOBJDIR
 Directory to use as the

[Mikko Rapeli-4]

On Tue, Oct 14, 2008 at 07:12:58PM +0200, Alan Barrett wrote:
> At present, build.sh ignores any MAKEFLAGS passed in the environment,
> and also ignores any MAKEFLAGS set via "-V MAKEFLAGS=value".  The
> appended patch makes build.sh ignore any MAKEFLAGS passed in the
> environment (as at present), but makes it accept "-V MAKEFLAGS=value".
> Does this address everybody's concerns?

To me this is fine, but I'm wondering when build.sh will start resetting
the whole environment and I'd have to rewrite a few build scripts
setting hundreds of variables to the -V style or to a MAKECONF...

-Mikko

[Greg A. Woods; Planix, Inc.]

On 17-Oct-08, at 1:47 AM, Mikko Rapeli wrote:
>
> To me this is fine, but I'm wondering when build.sh will start  
> resetting
> the whole environment and I'd have to rewrite a few build scripts
> setting hundreds of variables to the -V style or to a MAKECONF...

Hundreds?

You should be using one or more MAKECONF files!

(Are there even hundreds of variables that one could be setting?  Even  
including many duplicates (which are surrounded by .if's for different  
builds) and some which are identical to the defaults, I've only got 73  
in my mk.conf.)

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods@...>

[Mikko Rapeli-4]

On Fri, Oct 17, 2008 at 12:45:37PM -0400, Greg A. Woods; Planix, Inc. wrote:

> On 17-Oct-08, at 1:47 AM, Mikko Rapeli wrote:
> >
> >To me this is fine, but I'm wondering when build.sh will start  
> >resetting
> >the whole environment and I'd have to rewrite a few build scripts
> >setting hundreds of variables to the -V style or to a MAKECONF...
>
> Hundreds?
>
> You should be using one or more MAKECONF files!
>
> (Are there even hundreds of variables that one could be setting?  Even  
> including many duplicates (which are surrounded by .if's for different  
> builds) and some which are identical to the defaults, I've only got 73  
> in my mk.conf.)

CPUFLAGS_objectfile on each source file not compiling to or working in thumb
mode on ARM.

http://mail-index.netbsd.org/port-arm/2008/09/19/msg000387.html

-Mikko

[Greg A. Woods; Planix, Inc.]

On 20-Oct-08, at 1:37 AM, Mikko Rapeli wrote:

> On Fri, Oct 17, 2008 at 12:45:37PM -0400, Greg A. Woods; Planix,  
> Inc. wrote:
>> On 17-Oct-08, at 1:47 AM, Mikko Rapeli wrote:
>>>
>>> To me this is fine, but I'm wondering when build.sh will start
>>> resetting
>>> the whole environment and I'd have to rewrite a few build scripts
>>> setting hundreds of variables to the -V style or to a MAKECONF...
>>
>> Hundreds?
>>
>> You should be using one or more MAKECONF files!
>>
>> (Are there even hundreds of variables that one could be setting?  
>> Even
>> including many duplicates (which are surrounded by .if's for  
>> different
>> builds) and some which are identical to the defaults, I've only got  
>> 73
>> in my mk.conf.)
>
> CPUFLAGS_objectfile on each source file not compiling to or working  
> in thumb
> mode on ARM.
>
> http://mail-index.netbsd.org/port-arm/2008/09/19/msg000387.html

OK, I think, IIUC, what you've got there is a very special case, one  
which should not exist in the longer term.  (in the long term I think  
the toolchain should be fixed to properly support your target  
architecture and/or any remaining custom settings should be integrated  
into the relevant makefiles for the affected sources)

However for the short term I think a MAKECONF file, or file fragment  
that other MAKECONF files could include (if you have multiple source  
trees and/or build environments), to centralize all those special  
settings would be most appropriate -- much more appropriate than using  
a wrapper script which sets them all in environment variables.

--
                                        Greg A. Woods; Planix, Inc.
                                        <woods@...>