FMU_TESTING is gated on an undefined variable (ENABLE_FMU_EXPORT), so it can never be enabled

[DanNegrut]

src/chrono_fmi/CMakeLists.txt:51 guards FMU testing on a variable that does not exist:

cmake_dependent_option(FMU_TESTING "Enable FMU testing" ON "ENABLE_FMU_EXPORT" OFF)

ENABLE_FMU_EXPORT occurs exactly once in the whole repository, on that line, and is never defined
anywhere. The option the file actually uses for this everywhere else is FMU_EXPORT_SUPPORT, declared
20-odd lines earlier:

cmake_dependent_option(FMU_EXPORT_SUPPORT "Enable FMU export capabilities" ON "CH_ENABLE_MODULE_FMI" OFF)

Since cmake_dependent_option forces the option to its <force> value whenever the dependency
expression is false, and an undefined variable is false, FMU_TESTING is forced OFF and hidden
regardless of configuration. It does not appear in the CMake cache of a configured build. So FMU testing
cannot currently be switched on.

Introduced in 47ade30 ("Refactor Chrono::FMI to separate build requirements for FMU export and
import.", 2024-05-22), which renamed the export option; this one reference did not follow the rename.

The fix is presumably one word:

cmake_dependent_option(FMU_TESTING "Enable FMU testing" ON "FMU_EXPORT_SUPPORT" OFF)

I have not sent a patch because I have not confirmed what FMU_TESTING is supposed to gate, and whether
those tests currently pass, is worth knowing before it is turned on for everyone. Scope note on the
evidence: the single reference, the absent definition, and the absence of FMU_TESTING from a configured
cache are all verified. The claim that it would become settable after the rename follows from
cmake_dependent_option semantics and was not measured, since doing so needs a static build with
FMU_EXPORT_SUPPORT=ON.

Found while working on #762 / #772.

[DanNegrut]

Following up on my own "the fix is presumably one word". It is not, and I am glad I checked before sending a patch. Three things compound.

1. What FMU_TESTING gates. It is consumed in the fmu-forge submodule, fmi2/CMakeLists.txt:260 and fmi3/CMakeLists.txt:257, where it adds a POST_BUILD step running the vendored fmusim validation tool from Reference-FMUs against each generated FMU. It is user-facing and documented: src/demos/fmi/README.md tells users to enable it by "setting the FMU_TESTING CMake variable to ON". So this is a documented option that currently cannot be switched on at all.

2. The default is ON, and a failure is fatal. The option is declared cmake_dependent_option(FMU_TESTING "Enable FMU testing" ON ...), so repairing the dependency name does not merely make it settable, it turns validation on by default for anyone with FMU export enabled. And the wrapper is not advisory:

execute_process(COMMAND @FMUSIM_EXEC@ ... COMMAND_ERROR_IS_FATAL ANY RESULT_VARIABLE res_var)
if(NOT "${res_var}" STREQUAL "0")
  message(FATAL_ERROR "fmusim failed res_var='${res_var}'")

Any fmusim failure becomes a hard build failure.

3. The Linux fmusim binary is not executable. In fmu-forge, fmusim/fmusim.x86_64-linux is committed with mode 100644 rather than 100755:

100644 89d8633fff6b0d8885fddc66afc26ed1fd039413 0	fmusim/fmusim.x86_64-linux
100644 ef8d44d16a3aff3f006a9f15ed879f8a840645db 0	fmusim/fmusim.x86_64-windows.exe

Confirmed on a fresh Linux checkout, where running it gives bash: ./fmusim/fmusim.x86_64-linux: Permission denied. Windows is unaffected because it does not rely on a permission bit.

Consequence. Correcting the variable name on its own would enable validation by default, immediately fail to execute the tool on Linux, and turn that into a fatal build error. Every Linux build with FMU export enabled would stop working. So the change needs, in some order:

1. chmod +x on the vendored Linux binary in fmu-forge (mode 100755), which is a fmu-forge change rather than a Chrono one.
2. A decision on whether FMU_TESTING should really default to ON once it becomes reachable, or default OFF and be opt-in as the fmu-forge examples treat it (FMU_TESTING (optional, default OFF) per the comment at the top of both files).
3. The one-word rename here.

Item 2 is yours to decide. I am happy to send the Chrono-side one-liner once 1 and 2 are settled, or to leave the whole thing to you since it spans both repositories.

Not verified: whether fmusim actually passes on the current Chrono FMUs once it can run. That needs items 1 and 2 resolved first, and the README does claim "All Chrono example FMUs provided here have been validated with fmusim".