Date: Wed, 21 Jan 2004 12:00:19 -0500 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: OPTIONSFILE path [HEADS UP: New bsd.*.mk changes] Message-ID: <1074704419.768.41.camel@gyros> In-Reply-To: <400EA9E4.3040004@fillmore-labs.com> References: <1074617147.757.16.camel@gyros> <20040120171315.GH94636@FreeBSD.org> <1074619795.757.43.camel@gyros> <400D68A1.4030501@fillmore-labs.com> <1074620919.757.51.camel@gyros> <20040120175136.GC3365@toxic.magnesium.net> <400D6D8F.7010708@fillmore-labs.com> <1074621945.757.63.camel@gyros> <400D7077.30009@fillmore-labs.com> <1074622845.757.69.camel@gyros> <20040120184123.GI94636@FreeBSD.org> <1074637133.757.128.camel@gyros> <400EA9E4.3040004@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-ff0yDfp24aPBBTXJbWzH
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2004-01-21 at 11:33, Oliver Eikemeier wrote:
[I think we're all on the same page at this point.]
>=20
> I admit that I'm not very happy with what seems to be making a mountain o=
ut 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.
>=20
> - 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.
>=20
> I can offer a patch which does the following:
>=20
> - 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
>=20
> 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:
>=20
> LATEST_LINK=3D myport123${PKGNAMESUFFIX}
>=20
> .include <bsd.port.pre.mk>
>=20
> .if defined(CLIENT_ONLY)
> PKGNAMESUFFIX=3D -client
> .else
> PKGNAMESUFFIX=3D -server
> .endif
>=20
> She gets /var/db/ports/myport123/options for both -client and -server par=
ts.
> `make config' sees /var/db/ports/myport123-server/options, though. Of cou=
rse
> I can play the same game with UNIQUENAME, so setting LATEST_LINK aside do=
es
> not really buy anything.
>=20
> This patch tries to guard against this by evaluating OPTIONSFILE early an=
d
> checking if this value does not change.
>=20
> Some more changes are:
>=20
> - bring the =3D=3D=3D> messages in line with the existing ones by using P=
KGNAME
> 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 fou=
nd
Good.
> - make the output of the showconfig target a little more user friendly, e=
ven
> 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.
>=20
> 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
--=20
Joe Marcus Clarke
FreeBSD GNOME Team :: marcus@FreeBSD.org
gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
--=-ff0yDfp24aPBBTXJbWzH
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQBADrAjb2iPiv4Uz4cRAqH1AKCAeTMCIOYyjtNfToxbR95EzLfnIQCeLNh6
qa0+4CLulg36sjX0MZ/xpso=
=0ff8
-----END PGP SIGNATURE-----
--=-ff0yDfp24aPBBTXJbWzH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1074704419.768.41.camel>