Date: Tue, 24 Oct 2006 20:44:11 +0400 From: Ruslan Ermilov <ru@FreeBSD.org> To: Florent Thoumie <flz@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, Jeremie Le Hen <jeremie@le-hen.org> Subject: Re: src.conf(5) seems to affect ports build Message-ID: <20061024164411.GE21304@rambler-co.ru> In-Reply-To: <1161703420.16172.23.camel@mayday.esat.net> References: <20061020150848.GQ53114@obiwan.tataz.chchile.org> <20061020191332.GC59856@rambler-co.ru> <20061021162635.GS53114@obiwan.tataz.chchile.org> <20061021172533.GA69551@rambler-co.ru> <20061022153436.GW53114@obiwan.tataz.chchile.org> <20061024134800.GB20819@rambler-co.ru> <1161703420.16172.23.camel@mayday.esat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--M/SuVGWktc5uNpra
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 24, 2006 at 04:23:40PM +0100, Florent Thoumie wrote:
> On Tue, 2006-10-24 at 17:48 +0400, Ruslan Ermilov wrote:
> > On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
> > > Ruslan,
> > >=20
> > > On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
> > > > > Also, your patch avoids performing the WITH(OUT)_* stuff for port=
s in
> > > > > order to prevent from polluting the namespace. If there is to be
> > > > > some WITH(OUT)_* knobs which leads to CFLAGS modification in the =
future
> > > > > (I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn'=
t it
> > > > > be worth benefiting this framework for ports ?
> > > >
> > > > It avoids only /etc/src.conf stuff when running bsd.port.mk; if you=
put
> > > > WITH(OUT)_* in /etc/make.conf it will still be picked up.
> > >=20
> > > Yes indeed, but MK_FOO won't be set and this would require to either
> > > duplicate the code that modifies CFLAGS, or at least test for MK_FOO
> > > or WITH_FOO at the same time.
> > >=20
> > > Let me show you an example.
> > >=20
> > > I have an additional <bsd.ssp.mk> that is included from both bsd.sys.=
mk
> > > and bsd.port.mk:
> > >=20
> > > % .if ${MK_SSP} !=3D "no"
> > > % SSP_CFLAGS ?=3D -fstack-protector
> > > % CFLAGS +=3D ${SSP_CFLAGS}
> > > % . if defined(WARNS) && ${WARNS} >=3D 7 && !empty(SSP_CFLAGS)
> > > % CWARNFLAGS +=3D -Wstack-protector
> > > % . endif
> > > % .endif
> > >=20
> > > Currently it is thus quite useful to use MK_SSP when this file is
> > > included from bsd.ports.mk. With your whole patch I would have to
> > > either duplicate these bits in bsd.ports.mk or turn the condition to
> > > something like:
> > >=20
> > > % .if (defined(MK_SSP) && ${MK_SSP} !=3D "no") || defined(WITH_SSP)
> > >=20
> > > What do you advice me to do ?
> > >=20
> > I still don't understand why my patch created a problem for you.
> > This option is not in bsd.own.mk, so it's not covered by my patch.
> > All my patch does is "don't process /etc/src.conf" which is entirely
> > for src/.
> >=20
> > So, you can continue to use your bsd.ssp.mk as before, and my patch
> > shouldn't influence it.
> >=20
> > If you want to really mimic the standard behavior, then bsd.ssp.mk
> > should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
> > to "yes/no", accordingly; setting MK_SSP by a user shouldn't be
> > allowed or supported. You then set WITH_SSP=3D in /etc/make.conf
> > (or in /etc/src.conf if you want it only for src/), or pass
> > -DWITH_SSP on the make command line, and you're done.
> >=20
> > P.S. There has been a patch floating around that adds support for
> > /etc/ports.conf.
>=20
> [...] that you sent :-)
>=20
> Could try to revive the thread with a new patch.
>=20
Better just commit something. :-)
Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
--M/SuVGWktc5uNpra
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFPkLbqRfpzJluFF4RAuE/AJsG4v/WZSUj6yjCPZ/P19nanj55cgCfQHi7
BeH78IjYK+icyjvsQBhy1/4=
=J3mn
-----END PGP SIGNATURE-----
--M/SuVGWktc5uNpra--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061024164411.GE21304>