Questions about/issues with new OPTIONS framework

Tue Aug 7 21:02:42 UTC 2012

On 2012-08-07 21:30, Jeremy Chadwick wrote:
> On Tue, Aug 07, 2012 at 08:43:18PM +0200, Olli Hauer wrote:
>> On 2012-08-06 18:04, Jeremy Chadwick wrote:
>>> (Please keep me CC'd, as I'm not subscribed to the list)
>>>
>>> I've been trying to adapt my /etc/make.conf to make use of the new
>>> OPTIONS framework.  I've run into some snags that I was hoping someone
>>> could help me with, as I'm unable to find any "official" documentation
>>> other than these two documents, which don't help me in this case:
>>>
>>> http://wiki.freebsd.org/Ports/Options/OptionsNG
>>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html
>>>
>>> Below are my questions so far.  Note that these questions are all
>>> preceded by a key fact: /var/db/ports/* is completely empty.  Keep that
>>> in mind please.
>>>
>>> 1. databases/mysql55-server and databases/mysql55-client both ask for
>>> the same variables (OPENSSL and FASTMTX).  I want FASTMTX to be enabled
>>> by default for both ports.
>>>
>>> When I have the following in /etc/make.conf:
>>>
>>> mysql_SET=	FASTMTX
>>>
>>> Doing "make config" in databases/mysql55-server shows FASTMTX as checked
>>> (which is correct).  However, when I do the exact same procedure in
>>> databases/mysql55-client, FASTMTX is not checked.
>>>
>>> I am aware that databases/mysql55-client is a slave port, but I'm not
>>> sure how/why that would matter...?
>>>
>>> What am I doing wrong, or is this a port bug which needs to be fixed by
>>> the maintainer?
>>>
>>> 2. ports/KNOBS is very explicit in stating, and even visually
>> ...
>>
>> 2) alredy answerd ...
>>
>> answer for question 1)
>>
>> $> cd mysql55-client && make -V UNIQUENAME
>> or
>> $> make -V UNIQUENAME -C /usr/ports/databases/mysql55-client/
>>  mysql55-client
> 
> So it's based off of UNIQUENAME?  That's interesting.
> 
> The ""documentation"" implies that the name of the variable itself
> should be the {nameofport}_SET or {nameofport}_UNSET, where {nameofport}
> should equal the name of the actual port directory you're in.  Yet, take
> a look at this:
> 
> root at icarus:/usr/ports/devel/apr0 # make -V UNIQUENAME
> apr
> 
> root at icarus:/usr/ports/devel/apr1 # make -V UNIQUENAME
> apr
> 
> root at icarus:/usr/ports/devel/apr2 # make -V UNIQUENAME
> apr
> 
> Another one where the names are consistent (mtr-nox11 is a stub/slave
> port):
> 
> root at icarus:/usr/ports/net/mtr # make -V UNIQUENAME
> mtr
> 
> root at icarus:/usr/ports/net/mtr-nox11 # make -V UNIQUENAME
> mtr
> 
> All of these consistently use the same UNIQUENAME.  To me that seems
> like the Right Choice(tm), but then there's this:
> 
> root at icarus:/usr/ports/databases/mysql55-server # make -V UNIQUENAME
> mysql
> 
> root at icarus:/usr/ports/databases/mysql55-client # make -V UNIQUENAME
> mysql55-client
> 
> I would imagine these should return the same thing (e.g. mysql55-client
> should have a UNIQUENAME of mysql, or alternately mysql55-server should
> have a UNIQUENAME of mysql55-server).
> ...while for other ports, it does seem to be based off of the port name
> itself.  Examples ports include apache22-itk-mpm, p5-DBD-mysql,
> p5-libwww, and so on.
> 

For MySQL server / client sharing the same OPTIONSFILE would make sense
since they have exact the same OPTIONS.

Problematic is where a MASTER port has different options then the slave,
(server/client) and are using the same OPTIONSFILE since then they start
overwrite the other port during `make config'.

It would be nice if an option file could be separated into a shared
and a private section (for example the apache port should honor options
from apr, but at the moment this is only a good wish :)

To answer the question how the UNIQUENAME is constructed
>From bsd.port.mk:

.if defined(LATEST_LINK)
UNIQUENAME?=    ${LATEST_LINK}
.else
UNIQUENAME?=    ${PKGNAMEPREFIX}${PORTNAME}
.endif

Some more to read about UNIQUENAME
http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/075887.html

Matthew Seaman has already a script to identify all problematic ports
http://lists.freebsd.org/pipermail/freebsd-ports/2012-June/076028.html

> How are users supposed to know what the name of the variable is they
> should be setting in make.conf?  There doesn't even appear to be a "make
> show-xxx" command to help people out with this.
> 
> Trial and error seems to be the only way to figure it out, and that's
> time-consuming.  Luckily this is my home system where I only have 81
> ports installed, and only a handful require adjustments, but you can see
> my point?

The only proof way at the moment is `make -V UNIQUENAME'

>> make.conf entry constructed from UNIQUENAME
>>  mysql55-client_SET+=	FASTMTX
>>
>> Please note the '+=' instead '='.
>> If you have a port where you set more then on option but not as one expression
>> all ${UNIQUENAME}_SET+= are applied else only the last entry in make.conf.
> 
> I don't quite understand your last paragraph (maybe a language barrier;
> I say that politely, not insultingly).  Can you rephrase for me?  Also
> how does OPTIONS_SET and OPTIONS_UNSET (talking about the "global"
> variables) fit into this?

I will try (stop thinking and then translate ...)

Say you have a port 'abc' and you want to set the OPTIONS 'D' 'E' 'F' to on

A)
abc_SET+= D E F

B)
abc_SET+=D
abc_SET+=E
abc_SET+=F

If you write in example B instead of '+=' '=' only abc_SET=F will be applied.

Even if you set the global variables OPTION_(UN)SET they will be overwritten
by the options you choose in the port, only way seems to use OPTIONS_OVERWRITE
and then fiddle out how to set the needed OPTION again to on (sick ...)

> Next: the ""documentation"" does not state to use '+=' on these entries
> in make.conf, it says to use '=':
> http://wiki.freebsd.org/Ports/Options/OptionsNG

See my examples, for testing I use sometimes multi lines instead all in one
line so I can comment one option with a '#' for testing (I don't want to use
`make config' to test several build options, keeping make.conf open in vi and
kicking vi in the background is my way to do test builds).

On the WIKI you can find both examples but not explicit for one OPTION
(there is also the ${UNIQUENAME}_(UN)SET for example)

> See, for example, the OPTIONS_SET and OPTIONS_UNSET examples, in
> addition to the zsh_SET and zsh_UNSET examples on that web page.
> 
> There's nothing about any of this framework in make.conf(5) either.

make.conf(5) is delivered by the base OS, so it cannot reflect actual changes.
I suspect the manpages will be updated as soon the framework is full implemented.

> This is frustrating.  There isn't even anything in ports/UPDATING about
> any of this, so what am I supposed to go off of?  :-(

Yes, but the handbooks are already updated
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html

>> Additional if you have done `make config' already, then your make.conf entry
>> is useless since with options NG the OPTIONSFILE has now a higher priority.
> 
> Absolutely -- and this is why I outlined (for my case anyway) that
> /var/db/ports was empty prior to me doing my tests.  I'm well-aware of
> the options file and how it takes precedence.  :-)
> 