[Bug]: Autoconf'ism in CMakeLists.txt

[BrianAker]

Contact Details

No response

Version

github

Description

From CMakeList.txt

add_option("WOLFSSL_CODING"
    "Enable coding base 16/64 (default: enabled)"
    "yes" "yes;no")

The above is an autoconf'ism(*). To have cmake's automation skills work for you, and all of the tooling around it, options need to be done in the style expected.

option(WOLFSSL_CODING "Enable coding base 16/64" ON)

cmake has a weakly typed boolean, so there are numerous values that will translate into "true", but by not using standard cmake syntax you are missing some number of benefits to cmake that cmake users will want.

I did look at function(add_option); is it a clever to turn bad input values into "some value". This will turn out very poorly for someone.

assert() !

This plainly allows corruption of builds based on not generating an error from invalid input.

*) FWIW even in autoconf, turning --enable-foo values into --foo=yes is pretty messy and is not good autoconf syntax. See AC_ARG_ENABLE().

Reproduction steps

No response

Relevant log output

No response

[haydenroche5]

Hi @BrianAker. I'm a bit confused by what you would suggest we change and also am curious if you can show me how this might "turn out very poorly for someone." The options, e.g. WOLFSSL_AESCCM (just picking a random one), should handle any CMake boolean (ON, OFF, 1, 0, etc.) correctly.

[BrianAker]

add_option() is reinventing the wheel, and the problem with doing this with CMake is that it breaks tools which can consume it/make the details of building libraries. Unlike Autoconf, CMake is is geared towards automation, so where with Autoconf convention rules, in CMake it is best used as design.
WOLFSSL_SHA224 is a good example, why reinvent a boolean operation?

[haydenroche5]

WOLFSSL_SHA224 is a good example, why reinvent a boolean operation?

I would agree if boolean options were the only types of options we need to support, but we have many options that aren't just binary yes/no. Take WOLFSSL_AESGCM as an example. It has many possible values: yes;no;table;small;word32;4bit. In the paradigm you're advocating, would we have separate options for all of these? i.e. WOLFSSL_AESGCM, WOLFSSL_AESGCM_SMALL, WOLFSSL_AESGCM_WORD32, WOLFSSL_AESGCM_4BIT? Please provide an example rewrite of one of these options for me to understand the benefits of your proposed refactor. It's still not clear to me.

the problem with doing this with CMake is that it breaks tools which can consume it/make the details of building libraries.

Please provide an example. I want to understand how this can break, but I'm still not making the connection.