Hacker News Reader

Comment by snnn | Hacker News Reader

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

View on HN

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.

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.

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.

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.

That's ... how autoconf works?

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

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

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

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

Reply on news.ycombinator.com