Question about new options framework (regression?)

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Question about new options framework (regression?)

Oliver Fromme
Hi,

What is the proper way to temporarily change an option on
the command line or within a script?

For example, I have a script that builds both dynamic and
static zsh binaries, without user intervention.  With the
old options system, the script set "WITH_ZSH_STATIC=true"
when building the port.  With the new options framework,
that doesn't work aymore.

Is there a variable that can be set to override what's read
from the options file?  If there is none, this feels like a
regression.

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Baptiste Daroussin-2
On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote:

> Hi,
>
> What is the proper way to temporarily change an option on
> the command line or within a script?
>
> For example, I have a script that builds both dynamic and
> static zsh binaries, without user intervention.  With the
> old options system, the script set "WITH_ZSH_STATIC=true"
> when building the port.  With the new options framework,
> that doesn't work aymore.
>
> Is there a variable that can be set to override what's read
> from the options file?  If there is none, this feels like a
> regression.
>
> Best regards
>    Oliver
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
> chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
> FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
>
> One Unix to rule them all, One Resolver to find them,
> One IP to bring them all and in the zone to bind them.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[hidden email]"
Examples:

cd /usr/ports/zsh/shells
$ make showconfig
===> The following configuration options are available for zsh-5.0.0:
     DEBUG=off: Install debug symbols
     DOCS=on: Build and install the documentation
     GDBM=off: Enable GDBM support (GPL)
     MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
     MEM=off: Enable zsh-mem options
     MULTIBYTE=on: multibyte character support
     PCRE=off: Use Perl Compatible Regular Expressions
     SECURE_FREE=on: Enable zsh-secure-free
     STATIC=off: Build static executable/libraries
===> Use 'make config' to modify these settings

$ OPTIONS_SET="STATIC" make showconfig
===> The following configuration options are available for zsh-5.0.0:
     DEBUG=off: Install debug symbols
     DOCS=on: Build and install the documentation
     GDBM=off: Enable GDBM support (GPL)
     MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
     MEM=off: Enable zsh-mem options
     MULTIBYTE=on: multibyte character support
     PCRE=off: Use Perl Compatible Regular Expressions
     SECURE_FREE=on: Enable zsh-secure-free
     STATIC=on: Build static executable/libraries
===> Use 'make config' to modify these settings

$ zsh_SET="STATIC" make showconfig
===> The following configuration options are available for zsh-5.0.0:
     DEBUG=off: Install debug symbols
     DOCS=on: Build and install the documentation
     GDBM=off: Enable GDBM support (GPL)
     MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
     MEM=off: Enable zsh-mem options
     MULTIBYTE=on: multibyte character support
     PCRE=off: Use Perl Compatible Regular Expressions
     SECURE_FREE=on: Enable zsh-secure-free
     STATIC=on: Build static executable/libraries
===> Use 'make config' to modify these settings

$ OPTIONS_OVERRIDE="STATIC" make showconfig
 ===> The following configuration options are available for zsh-5.0.0:
     DEBUG=off: Install debug symbols
     DOCS=off: Build and install the documentation
     GDBM=off: Enable GDBM support (GPL)
     MAILDIR=off: Enable support for Maildirs in MAIL(PATH)
     MEM=off: Enable zsh-mem options
     MULTIBYTE=off: multibyte character support
     PCRE=off: Use Perl Compatible Regular Expressions
     SECURE_FREE=off: Enable zsh-secure-free
     STATIC=on: Build static executable/libraries
===> Use 'make config' to modify these settings

OPTIONS_SET and zsh_SET are the two normal way of setting options in make.conf.
OPTIONS_SET being global and zsh_SET being specific.

With both make sure to either not have them in make.conf of have them define with ?= or +=

Be careful that they can be changed by OPTIONS_UNSET and zsh_UNSET from make.conf if any

on the other hand OPTIONS_OVERRIDE will deactivate all options setting what ever the defaults are,
what the saved configuration can be etc.

and run the make command with just the options defined in it activated

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Oliver Fromme
Baptiste Daroussin <[hidden email]> wrote:
 > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote:
 > > What is the proper way to temporarily change an option on
 > > the command line or within a script?
 > >
 > > For example, I have a script that builds both dynamic and
 > > static zsh binaries, without user intervention.  With the
 > > old options system, the script set "WITH_ZSH_STATIC=true"
 > > when building the port.  With the new options framework,
 > > that doesn't work aymore.
 > >
 > > Is there a variable that can be set to override what's read
 > > from the options file?  If there is none, this feels like a
 > > regression.
 >
 > $ OPTIONS_SET="STATIC" make showconfig
 > ===> The following configuration options are available for zsh-5.0.0:
 >      DEBUG=off: Install debug symbols
 >      DOCS=on: Build and install the documentation
 >      GDBM=off: Enable GDBM support (GPL)
 >      MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
 >      MEM=off: Enable zsh-mem options
 >      MULTIBYTE=on: multibyte character support
 >      PCRE=off: Use Perl Compatible Regular Expressions
 >      SECURE_FREE=on: Enable zsh-secure-free
 >      STATIC=on: Build static executable/libraries
 > ===> Use 'make config' to modify these settings

I'm afraid it doesn't work for me:

$ OPTIONS_SET="STATIC" make showconfig
===> The following configuration options are available for zsh-5.0.0:
     DEBUG=off: Install debug symbols
     DOCS=on: Build and install the documentation
     GDBM=off: Enable GDBM support (GPL)
     MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
     MEM=on: Enable zsh-mem options
     MULTIBYTE=on: multibyte character support
     PCRE=off: Use Perl Compatible Regular Expressions
     SECURE_FREE=on: Enable zsh-secure-free
     STATIC=off: Build static executable/libraries
===> Use 'make config' to modify these settings

I also tried the other settings you suggested, and none
of them works.  It's always overridden by the settings
that are stored in $PORT_DBDIR.

With the old framework, I could override $PORT_DBDIR with
"WITH_ZSH_STATIC=true" ...  Can't this be done with the
new framework, too?

Best regards
   Oliver


--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

Passwords are like underwear.  You don't share them,
you don't hang them on your monitor or under your keyboard,
you don't email them, or put them on a web site,
and you must change them very often.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Baptiste Daroussin-2
On Wed, Jul 25, 2012 at 07:09:48PM +0200, Oliver Fromme wrote:

> Baptiste Daroussin <[hidden email]> wrote:
>  > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote:
>  > > What is the proper way to temporarily change an option on
>  > > the command line or within a script?
>
> I also tried the other settings you suggested, and none
> of them works.  It's always overridden by the settings
> that are stored in $PORT_DBDIR.
>
> With the old framework, I could override $PORT_DBDIR with
> "WITH_ZSH_STATIC=true" ...  Can't this be done with the
> new framework, too?
This is because you already have a save configuration made out of make config

you can still override PORT_DBDIR to make sure this configuration is not read
PORT_DBDIR=/dev/null OPTIONS_SET="STATIC" make ..

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Oliver Fromme
Baptiste Daroussin <[hidden email]> wrote:
 > On Wed, Jul 25, 2012 at 07:09:48PM +0200, Oliver Fromme wrote:
 > > Baptiste Daroussin <[hidden email]> wrote:
 > > > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote:
 > > > > What is the proper way to temporarily change an option on
 > > > > the command line or within a script?
 > >
 > > I also tried the other settings you suggested, and none
 > > of them works.  It's always overridden by the settings
 > > that are stored in $PORT_DBDIR.
 > >
 > > With the old framework, I could override $PORT_DBDIR with
 > > "WITH_ZSH_STATIC=true" ...  Can't this be done with the
 > > new framework, too?
 >
 > This is because you already have a save configuration made out of make
 > config
 >
 > you can still override PORT_DBDIR to make sure this configuration is
 > not read
 > PORT_DBDIR=/dev/null OPTIONS_SET="STATIC" make ..

But I *do* want to use the saved configuration:  It enables
the MEM option, and maybe other things in the future.
I only want to override *one* option -- the STATIC option.
The others should be taken from the saved configuration in
the options file.

Well, of course, my script could try to parse the options
file, construct appropriate OPTIONS_SET and OPTIONS_UNSET
strings, and then add STATIC.  But I hoped that there still
is a simple way to override single settings from the options
file ...

I have to say it's a little annoying that I have to jump
through hoops to achieve something that was rather trivial
to do before.

Best regards
   Oliver


--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"With sufficient thrust, pigs fly just fine.  However, this
is not necessarily a good idea.  It is hard to be sure where
they are going to land, and it could be dangerous sitting
under them as they fly overhead." -- RFC 1925
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Scot Hetzel
In reply to this post by Oliver Fromme
On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:

> Baptiste Daroussin <[hidden email]> wrote:
>  > On Wed, Jul 25, 2012 at 05:11:18PM +0200, Oliver Fromme wrote:
>  > > What is the proper way to temporarily change an option on
>  > > the command line or within a script?
>  > >
>  > > For example, I have a script that builds both dynamic and
>  > > static zsh binaries, without user intervention.  With the
>  > > old options system, the script set "WITH_ZSH_STATIC=true"
>  > > when building the port.  With the new options framework,
>  > > that doesn't work aymore.
>  > >
>  > > Is there a variable that can be set to override what's read
>  > > from the options file?  If there is none, this feels like a
>  > > regression.
>  >
>  > $ OPTIONS_SET="STATIC" make showconfig
>  > ===> The following configuration options are available for zsh-5.0.0:
>  >      DEBUG=off: Install debug symbols
>  >      DOCS=on: Build and install the documentation
>  >      GDBM=off: Enable GDBM support (GPL)
>  >      MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
>  >      MEM=off: Enable zsh-mem options
>  >      MULTIBYTE=on: multibyte character support
>  >      PCRE=off: Use Perl Compatible Regular Expressions
>  >      SECURE_FREE=on: Enable zsh-secure-free
>  >      STATIC=on: Build static executable/libraries
>  > ===> Use 'make config' to modify these settings
>
> I'm afraid it doesn't work for me:
>
> $ OPTIONS_SET="STATIC" make showconfig
> ===> The following configuration options are available for zsh-5.0.0:
>      DEBUG=off: Install debug symbols
>      DOCS=on: Build and install the documentation
>      GDBM=off: Enable GDBM support (GPL)
>      MAILDIR=on: Enable support for Maildirs in MAIL(PATH)
>      MEM=on: Enable zsh-mem options
>      MULTIBYTE=on: multibyte character support
>      PCRE=off: Use Perl Compatible Regular Expressions
>      SECURE_FREE=on: Enable zsh-secure-free
>      STATIC=off: Build static executable/libraries
> ===> Use 'make config' to modify these settings
>
> I also tried the other settings you suggested, and none
> of them works.  It's always overridden by the settings
> that are stored in $PORT_DBDIR.
>
> With the old framework, I could override $PORT_DBDIR with
> "WITH_ZSH_STATIC=true" ...  Can't this be done with the
> new framework, too?
>
Reading thru the Mk/bsd.options.mk, it seems you should be able to do:

$ WITH_STATIC=true make showconfig

And it might override the saved settings from the OPTIONSFILE.

Scot
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

ohauer
On 2012-07-25 20:18, Scot Hetzel wrote:
> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:

>>
>> I also tried the other settings you suggested, and none
>> of them works.  It's always overridden by the settings
>> that are stored in $PORT_DBDIR.
>>
>> With the old framework, I could override $PORT_DBDIR with
>> "WITH_ZSH_STATIC=true" ...  Can't this be done with the
>> new framework, too?
>>
> Reading thru the Mk/bsd.options.mk, it seems you should be able to do:
>
> $ WITH_STATIC=true make showconfig
>
> And it might override the saved settings from the OPTIONSFILE.


No, this will not work.

$ make showconfig | grep STATIC
     STATIC=off: Build static executable/libraries

$ make -V LDFLAGS
 -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib


$ make -V LDFLAGS WITH_STATIC=true
 -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib

Expected result:
 -L/usr/local/lib -rpath=/usr/lib:/usr/local/lib -static


Seems we will see more such issues with slave ports since they cannot overwrite the optionsfile (maybe a fake target in the slave with make rmconfig can be a solution ;)

For me this is a regression which was already discussed on this list ( optionsng and tinderbox? )

I also ask with a simple example and got no answers ( options NG and slave/sub ports )
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

ohauer
In reply to this post by Scot Hetzel
On 2012-07-25 20:18, Scot Hetzel wrote:
> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:

The following diff will restore the old behavior so make.conf and command params have priority.
(Place the make.conf part after the OPTIONS_FILE_SET part)

Until now I cannot see why the OPTIONS file should always win.


Index: bsd.options.mk
===================================================================
--- bsd.options.mk      (revision 301530)
+++ bsd.options.mk      (working copy)
@@ -173,17 +173,6 @@
 .  include "${OPTIONSFILE}.local"
 .  endif

-### convert WITH and WITHOUT found in make.conf or reloaded from old optionsfile
-.for opt in ${ALL_OPTIONS}
-.if defined(WITH_${opt})
-PORT_OPTIONS+= ${opt}
-PORT_OPTIONS:= ${PORT_OPTIONS:O:u}
-.endif
-.if defined(WITHOUT_${opt})
-PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}}
-.endif
-.endfor
-
 ## Finish by using the options set by the port config dialog, if any
 .  for opt in ${OPTIONS_FILE_SET}
 .    if !empty(COMPLETE_OPTIONS_LIST:M${opt})
@@ -199,6 +188,17 @@

 .endif

+### convert WITH and WITHOUT found in make.conf or reloaded from old optionsfile
+.for opt in ${ALL_OPTIONS}
+.if defined(WITH_${opt})
+PORT_OPTIONS+= ${opt}
+PORT_OPTIONS:= ${PORT_OPTIONS:O:u}
+.endif
+.if defined(WITHOUT_${opt})
+PORT_OPTIONS:= ${PORT_OPTIONS:N${opt}}
+.endif
+.endfor
+
 ## Now some compatibility
 .if empty(PORT_OPTIONS:MDOCS)
 NOPORTDOCS=    yes
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Baptiste Daroussin-2
On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
> On 2012-07-25 20:18, Scot Hetzel wrote:
> > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
>
> The following diff will restore the old behavior so make.conf and command params have priority.
> (Place the make.conf part after the OPTIONS_FILE_SET part)
>
> Until now I cannot see why the OPTIONS file should always win.
>

because the priority goes to global to specific and the most specific is the
options file.

if most people want the options file to not have the final priority, why not,
can others spread their opinion here?

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

ohauer
On 2012-07-26 00:57, Baptiste Daroussin wrote:

> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
>> On 2012-07-25 20:18, Scot Hetzel wrote:
>>> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
>>
>> The following diff will restore the old behavior so make.conf and command params have priority.
>> (Place the make.conf part after the OPTIONS_FILE_SET part)
>>
>> Until now I cannot see why the OPTIONS file should always win.
>>
>
> because the priority goes to global to specific and the most specific is the
> options file.
>
> if most people want the options file to not have the final priority, why not,
> can others spread their opinion here?
>


The power of make.conf was to specify / overwrite a dedicated behavior (same like src.conf) globally or per directory regardless what is defined in options.

A valid use case was given with shell/zsh.

Say someone don't want to have DB-A in the network (because of the license ...) and set global without DB-A and use DB-B instead, once there is an options file you loose.

I have make.conf in svn and from there it is deployed to all systems to make sure they end up as specified, defining PORT_DBDIR=/dev/null is not handy.

Again, how would you overwrite from a slave an option which was set once before with make config on the master port? (with working example please)

Additional I suspect a command arg is more specific then a option which was set once.

--
Regards,
olli
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Eitan Adler-4
In reply to this post by Baptiste Daroussin-2
On 25 July 2012 15:57, Baptiste Daroussin <[hidden email]> wrote:

> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
>> On 2012-07-25 20:18, Scot Hetzel wrote:
>> > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
>>
>> The following diff will restore the old behavior so make.conf and command params have priority.
>> (Place the make.conf part after the OPTIONS_FILE_SET part)
>>
>> Until now I cannot see why the OPTIONS file should always win.
>>
>
> because the priority goes to global to specific and the most specific is the
> options file.
>
> if most people want the options file to not have the final priority, why not,
> can others spread their opinion here?

An option specified on the command line is more specific and should
have priority over saved values or configuration files.

--
Eitan Adler
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Baptiste Daroussin-2
On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote:

> On 25 July 2012 15:57, Baptiste Daroussin <[hidden email]> wrote:
> > On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
> >> On 2012-07-25 20:18, Scot Hetzel wrote:
> >> > On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
> >>
> >> The following diff will restore the old behavior so make.conf and command params have priority.
> >> (Place the make.conf part after the OPTIONS_FILE_SET part)
> >>
> >> Until now I cannot see why the OPTIONS file should always win.
> >>
> >
> > because the priority goes to global to specific and the most specific is the
> > options file.
> >
> > if most people want the options file to not have the final priority, why not,
> > can others spread their opinion here?
>
> An option specified on the command line is more specific and should
> have priority over saved values or configuration files.
>
> --
> Eitan Adler
You can already do that:
OPTIONSFILE=/my/path/to/options make config

regards,
Bapt

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Eitan Adler-4
On 25 July 2012 21:55, Baptiste Daroussin <[hidden email]> wrote:
> You can already do that:
> OPTIONSFILE=/my/path/to/options make config

You can't set specific options on the command line without putting all
of them into a file?


--
Eitan Adler
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

ohauer
In reply to this post by Baptiste Daroussin-2
On 2012-07-26 06:55, Baptiste Daroussin wrote:

> On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote:
>> On 25 July 2012 15:57, Baptiste Daroussin <[hidden email]> wrote:
>>> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
>>>> On 2012-07-25 20:18, Scot Hetzel wrote:
>>>>> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
>>>>
>>>> The following diff will restore the old behavior so make.conf and command params have priority.
>>>> (Place the make.conf part after the OPTIONS_FILE_SET part)
>>>>
>>>> Until now I cannot see why the OPTIONS file should always win.
>>>>
>>>
>>> because the priority goes to global to specific and the most specific is the
>>> options file.
>>>
>>> if most people want the options file to not have the final priority, why not,
>>> can others spread their opinion here?
>>
>> An option specified on the command line is more specific and should
>> have priority over saved values or configuration files.
>>
>> --
>> Eitan Adler
>
> You can already do that:
> OPTIONSFILE=/my/path/to/options make config
>

Are you kidding?

> because the priority goes to global to specific and the most specific is the options file.

I suspect no one wants to maintain different option files.
As shown options file is not the most specific one, it's the command arg.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Baptiste Daroussin-2
On Thu, Jul 26, 2012 at 07:22:24AM +0200, Olli Hauer wrote:

> On 2012-07-26 06:55, Baptiste Daroussin wrote:
> > On Wed, Jul 25, 2012 at 07:40:56PM -0700, Eitan Adler wrote:
> >> On 25 July 2012 15:57, Baptiste Daroussin <[hidden email]> wrote:
> >>> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
> >>>> On 2012-07-25 20:18, Scot Hetzel wrote:
> >>>>> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
> >>>>
> >>>> The following diff will restore the old behavior so make.conf and command params have priority.
> >>>> (Place the make.conf part after the OPTIONS_FILE_SET part)
> >>>>
> >>>> Until now I cannot see why the OPTIONS file should always win.
> >>>>
> >>>
> >>> because the priority goes to global to specific and the most specific is the
> >>> options file.
> >>>
> >>> if most people want the options file to not have the final priority, why not,
> >>> can others spread their opinion here?
> >>
> >> An option specified on the command line is more specific and should
> >> have priority over saved values or configuration files.
> >>
> >> --
> >> Eitan Adler
> >
> > You can already do that:
> > OPTIONSFILE=/my/path/to/options make config
> >
>
> Are you kidding?
Sorry I misunderstood Eitan mail :)
>
> > because the priority goes to global to specific and the most specific is the options file.
>
> I suspect no one wants to maintain different option files.
> As shown options file is not the most specific one, it's the command arg.



attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Jase Thew-3
In reply to this post by Baptiste Daroussin-2
On 25/07/2012 23:57, Baptiste Daroussin wrote:

> On Wed, Jul 25, 2012 at 11:24:27PM +0200, Olli Hauer wrote:
>> On 2012-07-25 20:18, Scot Hetzel wrote:
>>> On Wed, Jul 25, 2012 at 12:09 PM, Oliver Fromme <[hidden email]> wrote:
>>
>> The following diff will restore the old behavior so make.conf and command params have priority.
>> (Place the make.conf part after the OPTIONS_FILE_SET part)
>>
>> Until now I cannot see why the OPTIONS file should always win.
>>
>
> because the priority goes to global to specific and the most specific is the
> options file.
>
> if most people want the options file to not have the final priority, why not,
> can others spread their opinion here?
>
> regards,
> Bapt
>
I can't see why it would be of benefit for saved options to override
anything passed to make (either env or as an arg), as one of the reasons
you're likely to be passing them is to override any saved settings in
the first place.

Please consider reverting back to the established and I daresay,
expected behaviour.

Regards,

Jase.

--
Jase Thew
[hidden email]
FreeBSD Ports Committer



signature.asc (742 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Oliver Fromme

Jase Thew wrote:
 > On 25/07/2012 23:57, Baptiste Daroussin wrote:
 > > because the priority goes to global to specific and the most specific is the
 > > options file.
 > >
 > > if most people want the options file to not have the final priority, why not,
 > > can others spread their opinion here?
 >
 > I can't see why it would be of benefit for saved options to override
 > anything passed to make (either env or as an arg), as one of the reasons
 > you're likely to be passing them is to override any saved settings in
 > the first place.
 >
 > Please consider reverting back to the established and I daresay,
 > expected behaviour.

I agree with Jase.

Actually I'm not sure if PORTS_DBDIR should override make.conf
or vice versa.  I don't know which one should be regarded as
more specific.

But anything specified on the commandline is definitely more
specific than PORTS_DBDIR and should override anything else.

One way to do that would be to introduce another pair of
variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could
type:  make OVERRIDE_SET=STATIC

Best regards
   Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C++ is the only current language making COBOL look good."
        -- Bertrand Meyer
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

dougb
On 7/26/2012 7:41 AM, Oliver Fromme wrote:

>
> Jase Thew wrote:
>  > On 25/07/2012 23:57, Baptiste Daroussin wrote:
>  > > because the priority goes to global to specific and the most specific is the
>  > > options file.
>  > >
>  > > if most people want the options file to not have the final priority, why not,
>  > > can others spread their opinion here?
>  >
>  > I can't see why it would be of benefit for saved options to override
>  > anything passed to make (either env or as an arg), as one of the reasons
>  > you're likely to be passing them is to override any saved settings in
>  > the first place.
>  >
>  > Please consider reverting back to the established and I daresay,
>  > expected behaviour.
>
> I agree with Jase.
>
> Actually I'm not sure if PORTS_DBDIR should override make.conf
> or vice versa.  I don't know which one should be regarded as
> more specific.

Traditionally the precedence has been:

make.conf < OPTIONS < command line

The reason is that you want to set global options as high up as
possible, and then be able to override things for specific ports, and
specific builds.

We were promised that this would work with the new OPTIONS, it's
disappointing to here that it isn't.

> But anything specified on the commandline is definitely more
> specific than PORTS_DBDIR and should override anything else.

Right.

> One way to do that would be to introduce another pair of
> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could
> type:  make OVERRIDE_SET=STATIC

That shouldn't be necessary. The code should DTRT, as it did previously.

Doug

--

    Change is hard.



_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Jeremy Messenger-2
On Thu, Jul 26, 2012 at 11:39 AM, Doug Barton <[hidden email]> wrote:

> On 7/26/2012 7:41 AM, Oliver Fromme wrote:
>>
>> Jase Thew wrote:
>>  > On 25/07/2012 23:57, Baptiste Daroussin wrote:
>>  > > because the priority goes to global to specific and the most specific is the
>>  > > options file.
>>  > >
>>  > > if most people want the options file to not have the final priority, why not,
>>  > > can others spread their opinion here?
>>  >
>>  > I can't see why it would be of benefit for saved options to override
>>  > anything passed to make (either env or as an arg), as one of the reasons
>>  > you're likely to be passing them is to override any saved settings in
>>  > the first place.
>>  >
>>  > Please consider reverting back to the established and I daresay,
>>  > expected behaviour.
>>
>> I agree with Jase.
>>
>> Actually I'm not sure if PORTS_DBDIR should override make.conf
>> or vice versa.  I don't know which one should be regarded as
>> more specific.
>
> Traditionally the precedence has been:
>
> make.conf < OPTIONS < command line
>
> The reason is that you want to set global options as high up as
> possible, and then be able to override things for specific ports, and
> specific builds.
>
> We were promised that this would work with the new OPTIONS, it's
> disappointing to here that it isn't.

I don't know anything about the promise, but I do agree about that
it's disappoint that make.conf (global options) isn't first.

>> But anything specified on the commandline is definitely more
>> specific than PORTS_DBDIR and should override anything else.
>
> Right.
>
>> One way to do that would be to introduce another pair of
>> variables, e.g. OVERRIDE_SET and OVERRIDE_UNSET, so you could
>> type:  make OVERRIDE_SET=STATIC
>
> That shouldn't be necessary. The code should DTRT, as it did previously.
>
> Doug
>
> --
>
>     Change is hard.
>
>
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "[hidden email]"



--
[hidden email] - [hidden email]
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - [hidden email]
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Question about new options framework (regression?)

Oliver Fromme
In reply to this post by dougb

Doug Barton wrote:
 > Traditionally the precedence has been:
 >
 > make.conf < OPTIONS < command line

Are you sure?  But how did the old framework find out if a
WITH_* / WITHOUT_* variable came from make.conf or from the
command line?

For example, say the make environment contains WITH_FOO=YES,
but the OPTIONS file contains WITHOUT_FOO=YES.  If the above
precedence is to be followed, then the framework needed to
find out whether the WITH_FOO setting came from make.conf or
from the command line.  I don't think there's an easy way to
do that.

Best regards
   Oliver


--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Python tricks" is a tough one, cuz the language is so clean. E.g.,
C makes an art of confusing pointers with arrays and strings, which
leads to lotsa neat pointer tricks; APL mistakes everything for an
array, leading to neat one-liners; and Perl confuses everything
period, making each line a joyous adventure <wink>.
        -- Tim Peters
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
12