Print a warning if we try to WITHOUT_ an option which is marked as
"required" (and forced on).
Suggested by: emaste, imp
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D40613
Options on this list will be forced to 'yes'. This is intended for use
as a transitional measure when an option is ceasing to be optional,
before all of the associated make logic is removed.
Differential Revision: https://reviews.freebsd.org/D40590
Many people are used to gnu configure's behavior of changing
--with-foo=no to --without-foo. At the same time, several folks have
WITH_FOO=no in their config files to enable this ironic form of the
option because of an old meme from IRC, a mailing list or the forums (I
forget which). Add a warning to allow to alert people w/o breaking POLA.
Reviewed by: allanjude, bdrewery, manu
MFC After: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30684
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.
Differential Revision: https://reviews.freebsd.org/D2011
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
BROKEN_OPTIONS are forced to "no" regardless of other settings.
Clients are expected change BROKEN_OPTIONS with +=. It will not
be unset, so other parts of the build system can have visibility
into the options that are broken on this platform, though this
should be very rare.
Differential Revision: https://reviews.freebsd.org/D2009
default. This restores more of the historical expectations that
were broken when we started disallowing both WITH_FOO and
WITHOUT_FOO to be defined.
[2] Document this new behavior, and improve the documentation in
general here.
Submitted by: sjg@ [1].
