Implement __ALWAYS_NO_OPTIONS

[imp]

Summary

Add support for specifying unsupported / broken options that override
any defaults or user specified actions on the command line. This would
be useful for specifying features that are always broken or that
cannot make sense on a specific architecture, like ACPI on pc98 or
EISA on !i386 (!x86 usage of EISA is broken and there's no supported
hardware that could have it in any event). Any items in
__ALWAYS_NO_OPTIONS are forced to "no" regardless of other settings.

[andrew]

Should we signal an error if you try to set any of the options in __ALWAYS_NO_OPTIONS?

[imp]

In D2009#4, @andrew wrote:

Should we signal an error if you try to set any of the options in __ALWAYS_NO_OPTIONS?

That's a good question. We'd need an explicit WITH_FOO for any option in __ALWAYS_NO_OPTIONS. Generally, I think this is a good idea. My concern would be that the way things are setup now it might be hard to detect. Also, stuff like WITH_CTF may need to be special cased because of the goofy way we've had to do things there lead to many people putting that into their /etc/make.conf files just to enable DTRACE or some such. Then they'd have issues if they went to MIPS where dtrace isn't even a gleam in anybody's eye at the moment...

[emaste]

share/mk/bsd.mkopt.mk

69 ↗

(On Diff #4114)

I would like to test __ALWAYS_NO_OPTIONS to enable a default binutils port/pkg (D2005). What do you think about avoiding the .undef?

[imp]

In D2009#7, @emaste wrote:

I would like to test __ALWAYS_NO_OPTIONS to enable a default binutils port/pkg (D2005). What do you think about avoiding the .undef?

In theory, that's supposed to be an opaque detail of implementation to the Makefile clients, just like the defaults. I'd rather not people know how an option came to be disabled.

However, it is a nice, generic way to do what you want to do. Maybe I could rename it to BROKEN_OPTIONS instead?

[emaste]

In D2009#8, @imp wrote:

In theory, that's supposed to be an opaque detail of implementation to the Makefile clients, just like the defaults. I'd rather not people know how an option came to be disabled.

However, it is a nice, generic way to do what you want to do. Maybe I could rename it to BROKEN_OPTIONS instead?

Fair enough, that sounds good to me.

[andrew]

In D2009#6, @imp wrote:

In D2009#4, @andrew wrote:

Should we signal an error if you try to set any of the options in __ALWAYS_NO_OPTIONS?

That's a good question. We'd need an explicit WITH_FOO for any option in __ALWAYS_NO_OPTIONS. Generally, I think this is a good idea. My concern would be that the way things are setup now it might be hard to detect. Also, stuff like WITH_CTF may need to be special cased because of the goofy way we've had to do things there lead to many people putting that into their /etc/make.conf files just to enable DTRACE or some such. Then they'd have issues if they went to MIPS where dtrace isn't even a gleam in anybody's eye at the moment...

Would something like the following not work?

.if defined(WITH_${var}) && !defined(WITHOUT_${var}) # WITHOUT always wins
.error "Unable to ..."
.endif

I thought there was some support for dtrace on MIPS, I was looking at some of the code yesterday to help my understanding of how a function should work (but this is a separate discussion).

share/mk/bsd.mkopt.mk

69 ↗

(On Diff #4114)

The comment at the top of the file indicates it may be included multiple times:

Both __DEFAULT_YES_OPTIONS and __DEFAULT_NO_OPTIONS are undef'd
after all this processing, allowing this file to be included
multiple times with different lists.

[imp]

In D2009#10, @andrew wrote:

In D2009#6, @imp wrote:

In D2009#4, @andrew wrote:

Should we signal an error if you try to set any of the options in __ALWAYS_NO_OPTIONS?

That's a good question. We'd need an explicit WITH_FOO for any option in __ALWAYS_NO_OPTIONS. Generally, I think this is a good idea. My concern would be that the way things are setup now it might be hard to detect. Also, stuff like WITH_CTF may need to be special cased because of the goofy way we've had to do things there lead to many people putting that into their /etc/make.conf files just to enable DTRACE or some such. Then they'd have issues if they went to MIPS where dtrace isn't even a gleam in anybody's eye at the moment...

Would something like the following not work?

.if defined(WITH_${var}) && !defined(WITHOUT_${var}) # WITHOUT always wins
.error "Unable to ..."
.endif

That would catch things, yes. However, it would catch too many things due to the bogus recommendations
that we've had to give to define WITH_CTF in /etc/make.conf files. Today, if you do that, you can build MIPS
without a problem. If I were to add that, all of a sudden you couldn't build MIPS.

I thought there was some support for dtrace on MIPS, I was looking at some of the code yesterday to help my understanding of how a function should work (but this is a separate discussion).

Some, maybe. I've seen some atomics, for example. But it isn't much beyond that point.

[imp]

share/mk/bsd.mkopt.mk

69 ↗

(On Diff #4114)

Yes. If we were to do some kind of BROKEN_OPTIONS thing, however, you'd always have to += it, and it would persist. Persisting causes big issues for __DEFAULT_*OPTIONS, or maybe used to, since we used to whine when multiple definitions of MK_foo happened.

[imp]

Closed by commit rS279898 (authored by @imp).