OPTIONSFILE path [HEADS UP: New bsd.*.mk changes]

[Joe Marcus Clarke]

On Wed, 2004-01-21 at 11:33, Oliver Eikemeier wrote:

[I think we're all on the same page at this point.]

> 
> I admit that I'm not very happy with what seems to be making a mountain out of
> a molehill, but OPTIONSFILE still doesn't work the way we want it to:

Agreed, but we went with an option that didn't have the potential of
breaking any existing bsd.port.mk functions.

> 
> - We need OPTIONSFILE in bsd.port.pre.mk to check for existing options.
> - WITH_*/WITHOUT_* options are available *after* bsd.port.pre.mk

Right.  That's noted in the OPTIONS comment at the top of bsd.port.mk.

> - Some ports set their PKGNAMESUFFIX depending on the options,
>   like -apache2 in www/mod_jk, or -nox11
> - Some ports need a different set of options depending on PKGNAMESUFFIX,
>   like -client and -server

True.  However, I would argue that in some of those cases, those options
should not be exposed to the end user since there are usually slave
ports set up that set those options (e.g. Mozilla, MySQL, OpenLDAP,
etc.).  I would never add WITH_GTK2 to Mozilla's OPTIONS since users
should be using mozilla[-devel]-gtk2 instead.

> 
> I can offer a patch which does the following:
> 
> - Uses ${PORT_DBDIR}/${UNIQUENAME}/options
>   if UNIQUENAME is defined
> - Uses ${PORT_DBDIR}/${LATEST_LINK}/options
>   if UNIQUENAME is undefined and LATEST_LINK is defined
> - Uses ${PORT_DBDIR}/${PKGNAMEPREFIX}${PORTNAME}/options
>   if UNIQUENAME and LATEST_LINK are undefined
> 
> This requires PKGNAMEPREFIX, UNIQUENAME and LATEST_LINK to be defined
> *before* including bsd.port.pre.mk. In the case of LATEST_LINK this
> still may be a source of confusion, because it normally depends on
> PKGNAMEPREFIX, e.g. if someone does:
> 
> LATEST_LINK=	myport123${PKGNAMESUFFIX}
> 
> .include <bsd.port.pre.mk>
> 
> .if defined(CLIENT_ONLY)
> PKGNAMESUFFIX=	-client
> .else
> PKGNAMESUFFIX=	-server
> .endif
> 
> She gets /var/db/ports/myport123/options for both -client and -server parts.
> `make config' sees /var/db/ports/myport123-server/options, though. Of course
> I can play the same game with UNIQUENAME, so setting LATEST_LINK aside does
> not really buy anything.
> 
> This patch tries to guard against this by evaluating OPTIONSFILE early and
> checking if this value does not change.
> 
> Some more changes are:
> 
> - bring the ===> messages in line with the existing ones by using PKGNAME
>   instead of PORTNAME

Good.

> - the same for the dialog title

Good.

> - use ECHO_CMD instead of ECHO_MSG to write the OPTIONSFILE comment,
>   add a line with the PKGNAME

Good.

> - issue a note during compiling that user-specified options have been found

Good.

> - make the output of the showconfig target a little more user friendly, even
>   though unformatted.

Okay.

> - eliminate some verbatim uses of dirname, rm and id

Please pull these diffs out.  We don't want to cloud this diff with
extraneous stuff.  Thanks.

> 
> Sorry for making all the fuss about the OPTIONS macro, but I think it's *bad*
> if somehow ports get compiled with unexpected options, and currently that is
> more than likely.

Well, technically, nothing is very likely now since I know of only two
ports that are using the new OPTIONS framework (maybe only
games/moonlander now).  And remember, porters can override all aspects
of the OPTIONSFILE name at this point, so problem ports can be worked
around.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	marcus at FreeBSD.org
gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20040121/3fd4a0da/attachment.bin