Makefile.inc1.patch

[Garrett Cooper]

On Jan 23, 2014, at 1:54 PM, Simon J. Gerraty <sjg at juniper.net> wrote:

> On Thu, 23 Jan 2014 13:30:12 -0800, Garrett Cooper writes:
>>> Not crazy about frobbing ${MAKE}
>> 
>> Neither am I, but .export is a bmake only feature. I=92m still using =
>> fmake :(.
> 
> Not necessarily a good excuse ;-)

fmake: "http://www.youtube.com/watch?v=dGFXGwHsD_A !!!!” :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 =
>> complex
>>> dancing to keep things working.
>> 
>> In this case though, this is complex dancing due to how the different =
>> stages stack upon one another in the build process and the fact that =
>> meta make isn=92t here (yet), so things have to be built in the right =
>> order. This method is one that I=92ve been using for quite some time =
>> without any side effects on multiple machines...
> 
> 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. 

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… the -DNO_* logic is a bit messy…

Curious to see what you have in mind :)..

Thanks for the input :)!
-Garrett