Makefile.inc1.patch

[Alan Somers]

On Thu, Jan 23, 2014 at 3:21 PM, Alan Somers <asomers at freebsd.org> wrote:
> 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

Works for me.  Do you want me to commit it for you?

>
>>
>> Thanks!
>> -Garrett