[snnn]

So for each optional feature we may need three build options:

1. Force enable 2. Enable if available 3. Force disable

Like,

   --enable_landlock=always
   --enable_landlock
   --disable_landlock

[glandium]

My rule of thumb is that things should never be disabled automatically. Make the test hard fail and print a message that the feature can be disabled.

[cperciva]

In my code I have a bunch of routines optimized for different platforms, e.g. using x86 AESNI instructions. Not all compilers support them, and they don't even make sense when compiling for a different CPU architecture.

It's much simpler to say "enable this if we can compile it" rather than detecting the compiler and target platform and throwing a mess of conditional compilation into an autoconf script.

[ComputerGuru]

That’s how you make unusable/uncompilable software. It might be a good rule for something security critical like ssh but not as a general rule.

[glandium]

I'd rather have people complaining about having to run configure a bunch of times to disable several features they don't have the libraries for than complaining that a feature doesn't work (because it ended up being disabled without them knowing).

Likewise, I'd rather distros figure out the hard way when a new release has a new feature and needs a new dependency rather than their users complain that a new feature is missing.

Principle of least surprises.

[xorcist]

That's ... how autoconf works?

If you explicitly set the enable-landlock flag, configure will fail when the feature doesn't compile.

[snnn]

A cmake option only has two values: ON or OFF. There is no unset. Because it is a boolean.

See: https://cmake.org/cmake/help/latest/command/option.html

[account42]

This is not actually true, you can check if variables have been defined in CMake.

[xorcist]

Right, but the boolean is set by an autoconf script, is it not?