Inconsistent behaviour between generic and project-specific variable definition when failing to enable a requested feature

[reuterbal]

What happened?

Features declared via ecbuild_add_option can have a default state (ON or OFF) and they can be requested as required or disabled by setting ENABLE_<FEATURE>=[ON|OFF].

Configuration should and will fail if a feature was requested to be enabled explicitly, but it fails to activate, e.g., because a condition isn't fulfilled.

Moreover, a project-specific overwrite can be used, e.g., when in a superbuild (e.g., via ecbundle) a feature is enabled or disabled broadly and its state should be chosen differently for a single project (say, -DENABLE_<FEATURE>=OFF -D<PROJ>_ENABLE_<FEATURE>=ON).

However, I have noticed, when the project-specific way of enabling a feature is used, the configuration will not fail - thus exposing inconsistent behaviour between the two ways of requesting features. I suspect this is a bug because the output is also misleading in this case.

What are the steps to reproduce the bug?

Consider the following reproducer:

cmake_minimum_required( VERSION 3.18.4 FATAL_ERROR )
find_package( ecbuild 3.4 REQUIRED )

project( proja LANGUAGES NONE VERSION 0.2 )
ecbuild_add_option(
    FEATURE FEATUREON
    DEFAULT ON
    CONDITION DEFINED FEATUREON_CONDITION
)
ecbuild_add_option(
    FEATURE FEATUREOFF
    DEFAULT OFF
    CONDITION DEFINED FEATUREOFF_CONDITION
)

With this, I can create the following matrix of behaviour: (I've done a module load cmake ecbuild before, and am deleting the build directory in-between the following commands)

1. All features disabled, as expected:

cmake -B build -S .
...
-- Feature FEATUREON was not enabled (also not requested) -- following condition was not met: DEFINED FEATUREON_CONDITION
-- Feature FEATUREOFF disabled

2. Requesting FEATUREON to be enabled fails as expected because of the condition:

cmake -B build -S . -DENABLE_FEATUREON=ON
...
CMake Error at /usr/local/apps/ecbuild/3.9.1/share/ecbuild/cmake/ecbuild_log.cmake:190 (message):
  CRITICAL - Feature FEATUREON cannot be enabled -- following
  condition was not met: DEFINED FEATUREON_CONDITION

3. Defining FEATUREON_CONDITION lets the previous command succeed, as expected:

cmake -B build -S . -DENABLE_FEATUREON=ON -DFEATUREON_CONDITION=ON
...
-- Feature FEATUREON enabled
-- Feature FEATUREOFF disabled

4. Using the project-specific request without fulfilling the condition lets the configure complete successfully but keeps the feature disabled. This is unexpected behaviour and the output "also not requested" is misleading. I would expect the configure to fail in this situation as well.

cmake -B build -S . -DPROJA_ENABLE_FEATUREON=ON
...
-- Feature FEATUREON was not enabled (also not requested) -- following condition was not met: DEFINED FEATUREON_CONDITION
-- Feature FEATUREOFF disabled

5. The feature enables fine this way if the condition is met, as expected, even if paired with the broad disabling, and the explicit warning tells the user about the overwrite:

cmake -B build -S . -DPROJA_ENABLE_FEATUREON=ON -DFEATUREON_CONDITION=ON -DENABLE_FEATUREON=OFF
...
CMake Warning at /usr/local/apps/ecbuild/3.9.1/share/ecbuild/cmake/ecbuild_log.cmake:162 (message):
  WARN - Both ENABLE_FEATUREON and PROJA_ENABLE_FEATUREON are set for
  feature FEATUREON.  Using PROJA_ENABLE_FEATUREON=ON
Call Stack (most recent call first):
  /usr/local/apps/ecbuild/3.9.1/share/ecbuild/cmake/ecbuild_add_option.cmake:166 (ecbuild_warn)
  CMakeLists.txt:5 (ecbuild_add_option)


-- Feature FEATUREON enabled
-- Feature FEATUREOFF disabled

6. The behaviour seems to be independent from whether the default value for the feature is ON or OFF:

cmake -B build -S . -DPROJA_ENABLE_FEATUREOFF=ON
...
-- Feature FEATUREON was not enabled (also not requested) -- following condition was not met: DEFINED FEATUREON_CONDITION
-- Feature FEATUREOFF was not enabled (also not requested) -- following condition was not met: DEFINED FEATUREOFF_CONDITION

Version

3.9.1

Platform (OS and architecture)

HPC2020

Relevant log output

Accompanying data

No response

Organisation

ECMWF

[wdeconinck]

Hi @marcosbento do you have free cycles to spend on this?

[marcosbento]

Hi @reuterbal , Hi @wdeconinck , I'm not sure about free cycles 😛, but I'll try having a look at this today or tomorrow.

[marcosbento]

Hi @reuterbal,

thank you for reporting this issue.

The detailed description helped a lot to pinpoint the problem, which was a simple mismatch between the way ENABLE_<FEATURE> and <project>_ENABLE_<FEATURE> were handled. The former was marking the feature as "explicitly requested", while the later was not being considered as such.

I've made the necessary changes to fix this and created PR #83.

[wdeconinck]

Hi @reuterbal @marcosbento has fixed this now and merged in develop. Please, could you check if it is all OK to make sure and then close this issue?

[marcosbento]

Hi @reuterbal the fix for this issue has been included in the release 3.10.0.