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

Joe Marcus Clarke marcus at FreeBSD.org
Wed Jan 21 09:00:31 PST 2004

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
>   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:
> .include <bsd.port.pre.mk>
> .if defined(CLIENT_ONLY)
> .else
> .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


> - the same for the dialog title


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


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


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


> - 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


Joe Marcus Clarke
FreeBSD GNOME Team	::	marcus at FreeBSD.org
gnome at FreeBSD.org
FreeNode / #freebsd-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

More information about the freebsd-ports mailing list