[CMake] Don't wrap command in ROOTTEST_COMPILE_MACRO in CMake target

[guitargeek]

Instead of running the root ... <macro>.C+ build step as the command
associated with a custom CMake target, just run the command directly in
the test added with add_test.

This simplification is possible because for the custom CMake target, no
dependencies are ever specified. This makes building it not different
from just running the underlying command directly.

Do some further CMake code simplifications in a second commit (more detail in the commit description).

[github-actions]

Test Results

    19 files      19 suites   3d 9h 1m 51s ⏱️
 3 658 tests  3 656 ✅   0 💤 2 ❌
67 869 runs  67 767 ✅ 100 💤 2 ❌

For more details on these failures, see this check.

Results for commit c273e07.

♻️ This comment has been updated with latest results.

[hahnjo]

Wrapping to command inside a Cmake target doesn't seem to be necessary, because in the test, the target is forced to be built without dependencies anyway (e.g. cmake --build . --target my_macro_test/fast --always-make when using makefiles).

This is only partially true, for Unix Makefiles. With Ninja, we don't use /fast nor --always-make AFAICT

[guitargeek]

The intention of the original macro is apparently to only build this one target that runs the command. The fact that this was not done correctly for Ninja doesn't mean that rebuilding all dependencies was the intended behavior. I suppose it was just not correctly implemented.

[hahnjo]

In principle makes sense to me; maybe rephrase the first commit message because it still sounds wrong that dependencies would be ignored "anyway".

Also adding @hageboeck because it's related to #19702

[hageboeck]

I find the explanation confusing. I'll come discuss this in person.

[hageboeck]

Much clearer, thank you!

[pcanal]

Simplify ROOTTEST_COMPILE_MACRO to shorten test command
Add include path and library path via environment variables

How does switching from an argument to an environment variable concretely help? If one ever tries to reproduce the failing compilation 'exactly', one now needs to copy paste (the extended version of):

      ROOT_LIBRARY_PATH="${CMAKE_CURRENT_BINARY_DIR}"
      ROOT_INCLUDE_PATH="${CMAKE_CURRENT_BINARY_DIR}"
      ${ROOT_root_CMD}
      -e "gSystem->SetBuildDir(\"${CMAKE_CURRENT_BINARY_DIR}\", true)"
      ${RootMacroDirDefines}
      -q -l -b ....

instead of the extended version of:

      ${ROOT_root_CMD}
      -e "gSystem->AddDynamicPath(\"${CMAKE_CURRENT_BINARY_DIR}\")"
      -e "gInterpreter->AddIncludePath(\"-I${CMAKE_CURRENT_BINARY_DIR}\")"
      -e "gSystem->SetBuildDir(\"${CMAKE_CURRENT_BINARY_DIR}\", true)"
      ${RootMacroDirDefines}
      -q -l -b ... 

[guitargeek]

How does switching from an argument to an environment variable concretely help? If one ever tries to reproduce the failing compilation 'exactly', one now needs to copy paste (the extended version of):

That's true, the difference is marginal. But steering include and library paths via environment variables compared to C++ statements feels a bit cleaner to me, and also I think this was a good opportunity to test that the ROOT_INCLUDE_PATH and ROOT_LIBRARY_PATH environment variables work as intended. These are not covered anywhere else in the tests.