On Sat, Jun 23, 2012 at 11:11:49AM +0200, Olli Hauer wrote: > On 2012-06-23 10:18, Baptiste Daroussin wrote: > > On Fri, Jun 22, 2012 at 06:14:00PM -0700, Doug Barton wrote: > >> On 06/22/2012 10:44, Olli Hauer wrote: > >>> On 2012-06-21 11:26, Ganael LAPLANCHE wrote: > >>>> On Wed, 20 Jun 2012 13:28:26 +0100, Matthew Seaman wrote > >>>> > >>>>> [...] > >>>>> Shouldn't make.conf / commandline settings override OPTIONSFILE rather > >>>>> than the other way round? Seems there's not much point in being able to > >>>>> set options from make.conf unless that is so, as OPTIONSFILE would be > >>>>> created more often than not whenever make(1) was invoked in the port's > >>>>> directory. > >>>> > >>>> I think that command-line options should always override file ones, but > >>>> the main problem here is that we cannot distinguish what comes from the > >>>> command line from what comes from make.conf. > >>>> > >>>> What would sound logical to me would be the following order of > >>>> precedence : > >>>> > >>>> make.conf -> overridden by option files -> overridden by command line > >>> > >>> > >>> This looks wrong to me. > >>> > >>> Options set in make.conf should not be overwritten by the option file > >>> else you don't need etc/make.conf at all. > >> > >> Right. make.conf and options files should be flipped in the example above. > >> > >> > >> Doug > >> > > Well the priority ordering the logical was to give the end word to the last > > user > > action. > > > > It goes from global to specific > > > > 1/ the global options (infrastructures) are applied > > 2/ the maintainer option (ports are applied) > > 3/ the user global options are applied (OPTIONS_{,UN}SET) > > 4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET) > > 5/ the dialog (make config) options are applied > > > > If that it looks not good to anyone, please comment (we can still change > > it) and > > please provide arguments. > > > > regards, > > Bapt > > > > > OK, in case of tinderbox or any other build system think about the following. > > You do a build for production or testing and it is required to always use > pgsql > and *really* avoid mysql (real use case in my prod builds, I don't care > about mysql only ports, I just stay away from them). > > Now you create a fresh build and set the proper build options in build.xxx or > inject a make.conf via post-extract hook since there you want to define with > two statements the dependencies. > - OPTIONS_UNSET+=MYSQL > - OPTIONS_SET+=PGSQL > > This will not work if the directives are overwritten by /4 and /5. > In case of ports-mgmt/tinderbox you will end with a mysql enabled tinderbox :( > > To prevent this you have to go over a whole build and all configure dialogs to > make sure this settings are in place which is not practical, time consuming > and error prone. > > Luckily at the moment /4 and /5 can be overwritten with the old WITH|OUT_$opt > directives since this logic is applied as last in bsd.options.mk > > So ether fix the logic or keep the old WITH|OUT_$opt logic in bsd.options.mk > so we can use make.conf last file of defense. > > -- > Regards, > olli
Well when you run from tinderbox or any automated build stuff, you don't run make config so 5 never occurs. 4/ is made to give a finer grain for specific options for a given ports and is set from make.conf so you can easily tune it for your tinderbox. regards, Bapt
pgpqobrrnTy5v.pgp
Description: PGP signature