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
pgpNssTSfm2RC.pgp
Description: PGP signature