Makefile.inc1.patch

[Alan Somers]

On Thu, Jan 23, 2014 at 3:15 PM, Garrett Cooper <yaneurabeya at gmail.com> wrote:
> On Jan 23, 2014, at 2:11 PM, Simon J. Gerraty <sjg at juniper.net> wrote:
>
>>>> 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 imagine it would make fixing it easier.
>>
>>>> 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_*?
>>
>> Yes - I expect that would be rare, but worth it for completness.
>> The important thing is a simple precidence rule.
>>
>>>> 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
>>
>> NO_* always wins, it allows a makefile to say "I don't care what you
>> want I cannot do that".
>>
>> Most places you see -DNO_* used could be -DWITHOUT_* if the semantics
>> were not broken as previously described.
>> NO_* should be mainly for makefiles to set - like NO_MAN= (i don't got
>> no man page man)
>>
>>> Curious to see what you have in mind :)..
>>
>> Look at contrib/bmake/Makefile
>
> Ok, I'll definitely look at that.
>
> Alan,
>
> As far as fixing your issue is concerned though, has a fix already been committed or does one still need to be committed? If the latter, does this suffice for today -- with the intent that it will get ripped out in favor of something cleaner in the [near] future?

Umm, I accidentally committed my earlier patch along with a different
change today.  Oops.  I'm currently testing your latest patch.  I'm
happy with committing it if it works.

-Alan

>
> Thanks!
> -Garrett