Date: Thu, 23 Jan 2014 14:01:07 -0800 From: Garrett Cooper <yaneurabeya@gmail.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>, brooks@freebsd.org Subject: Re: Makefile.inc1.patch Message-ID: <8D80A156-F649-4CA1-846A-DBAE9CC30627@gmail.com> In-Reply-To: <20140123215430.4B7B15807E@chaos.jnpr.net> References: <B4D2A908-715F-484F-8028-A1F38884AF3F@gmail.com> <CAOtMX2jQ24JCR2Ct8YKob4MKcHWMhVVv5XG-1usoPWqEOA2OQg@mail.gmail.com> <4A3E3984-73D3-4441-97A7-D58679EFF978@gmail.com> <9775878D-91AB-4BE4-ADFA-32D8DB582AA6@gmail.com> <20140123210308.0E1D65807E@chaos.jnpr.net> <EBDCAEEC-9485-4EA5-AA60-943EA70A3171@gmail.com> <20140123215430.4B7B15807E@chaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 23, 2014, at 1:54 PM, Simon J. Gerraty <sjg@juniper.net> wrote:
> On Thu, 23 Jan 2014 13:30:12 -0800, Garrett Cooper writes:
>>> Not crazy about frobbing ${MAKE}
>>=20
>> Neither am I, but .export is a bmake only feature. I=3D92m still =
using =3D
>> fmake :(.
>=20
> Not necessarily a good excuse ;-)
fmake: "http://www.youtube.com/watch?v=3DdGFXGwHsD_A !!!!=94 :D
It needs to die sometime, but Makefile.inc1 needs to continue to work =
with it (for the time being).
>>> The semantics in bsd.own.mk are quite broken and result in a lot of =
=3D
>> complex
>>> dancing to keep things working.
>>=20
>> In this case though, this is complex dancing due to how the different =
=3D
>> stages stack upon one another in the build process and the fact that =
=3D
>> meta make isn=3D92t here (yet), so things have to be built in the =
right =3D
>> order. This method is one that I=3D92ve been using for quite some =
time =3D
>> without any side effects on multiple machines...
>=20
> Actually a simple tweak to the bsd.own.mk semantics would alleviate of
> lot of the pain. Throwing errors if MK_* is already set, or if both
> WITH_* and WITHOUT_* are set makes the usage very messy indeed.
Yeah...
> For options.mk I allow MK_* to already be set and WITHOUT_* to take
> precedence over WITH_*. I also allow makefiles to have their own =
lists
> of options - separate the policy from the mechanism.
Would that fix this case though?
> I guess you could even allow a per-knob setting as to which takes
> precedence.=20
You mean override the default so WITH_* overrides WITHOUT_*?
> By simply allowing WITHOUT_* to overrule WITH_*, the Makefile.inc1 =
usage
> would be greatly simplified.
Maybe=85 the -DNO_* logic is a bit messy=85
Curious to see what you have in mind :)..
Thanks for the input :)!
-Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D80A156-F649-4CA1-846A-DBAE9CC30627>