[cmake] Do not auto force-enable or force-disable user CMake build options

[ferdymercury]

Messing up with the cache is dangerous (calling to problems), and users often complain about not having the control since the build system changes what they just passed as flag to the command line. Instead, convert these automatism into a helpful error message that the user can use as a hotfix to modify their build flags. This prevents surprises, annoying behind-the-scene changes, as well as bugs. Follows up on the philosophy of #23020

Fixes https://its.cern.ch/jira/browse/ROOT-10743

[github-actions]

Test Results

    23 files      23 suites   3d 23h 31m 38s ⏱️
 3 885 tests  3 883 ✅ 0 💤 2 ❌
79 672 runs  79 670 ✅ 0 💤 2 ❌

For more details on these failures, see this check.

Results for commit 8dad541.

♻️ This comment has been updated with latest results.

[pcanal]

@ferdymercury Can you add a comment to close the now seemingly superseded #18413 explaining where we actually ended up?

[ferdymercury]

Sure, comment added: #18413 (comment)
And CI errors fixed now.

[ferdymercury]

(asan failure seems unrelated)

[hageboeck]

Hello,

I think that's a great initiative, but I would approach this differently.

• First of all, I think we need to take a decision on what the "recommended" strategy is when a package is missing or a builtin can't be downloaded. Personally, I think that's up to the user: Install it, disable the component that requires it, or provide internet connection. Therefore, the hotfix suggestions (that are predominantly -Dcomponent=Off) seem to mostly go in the wrong direction.
• If you agree to the above, you will find that the HOTFIX_BUILD_FLAGS list will be mostly empty, so to shorten and simplify the code, I would remove it entirely.
• If the hotfix list is removed, it would be consequent to use one single list or string to collect all failure messages in one place, and one list (already exists) to collect definitely missing pacakges.

That would bring us to a point where with any kind of problem, one could do the following:

if(<thereIsAProblem>)
  string(APPEND SIS_FAILURE_MESSAGE "The x option contradicts y. Do <this> now.\\n")
endif()

# And at the very end of `SearchInstalledSoftware`:
if(DEFINED SIS_FAILURE_MESSAGE)
  message(FATAL_ERROR ${SIS_FAILURE_MESSAGE})
endif()

And if we are considering such a strategy, the ROOT_CHECK_CONNECTION macro can not only check the connection but also APPEND the relevant error message (see the inline comments).
Instead of adding 300 lines, this PR would probably even remove lines.

BTW: Not touching CACHE variables is great, thank you!

I didn't add comments to all instances that would need to be changed, but I hope it's clear what I have in mind.

[hageboeck]

Since these are not really about optional (i.e. can use it or not) packages, I think message(FATAL_ERROR ...) makes sense. There's no other choice anyway, so stopping immediately seems like a good solution to me.

[ferdymercury]

Hmm, I agree, but wouldn't it make sense to split these changes into two distinct Pull Requests ?

First PR: we only change from CACHE to "print suggestion" but leave everything in the same direction
Second PR: we change behavior, ie direction of the automatism (ON or OFF) and nature of errors

In this case:
set(cocoa OFF CACHE with STATUS becomes:
please add -Dcocoa=OFF with SEND_ERROR

Adding a FATAL_ERROR instead is something I thought of avoiding in a first PR, it was just a "STATUS" so SEND_ERROR is a bit more intermediate and coherent with the rest of things than a FATAL_ERROR. And it will take more time to do quickly build ROOT if those things come in waves as @pcanal mentioned.

But if you all think it's better to fix all these in one go, I am ok with that too!

[pcanal]

In this particular case, one question is whether having in the cache cocoa=ON is harmful on non MacOS platform. i.e. Does it change the behavior of the CMakeList or is it a innocuous as using -Drandom_characters=ON?

If it is innocuous, there is no real reason to fail and a STATUS or WARNING is enough.

If it is not innocuous, then indeed it needs to be disabled by the user (and/or we need to fix our code to make it innocuous :) ) and because the default is NOT on, we can get to the error case only if the user explicitly said -Dcocoa=ON so it no longer quite fit under the quick build ROOT scheme but in a I need something specific from my build and thus in this particular case a FATAL_ERROR might be justified (a specific example would be: I wanted to build on MacOS but I copy/pasted my command line in a linux windows instead ... in this case the 'right' action is not to fix the build but to move to the 'right' window instead).

[ferdymercury]

In this particular case, one question is whether having in the cache cocoa=ON is harmful on non MacOS platform. i.e. Does it change the behavior of the CMakeList or is it a innocuous as using -Drandom_characters=ON?

It's not innocous, if it's ON, it tries to compile src/CocoaConstants.mm etc etc. So it should be avoided and FATAL_ERROR makes sense.

and because the default is NOT on

cocoa defaults to ON on macos, so there is no need to add this flag in the command line. One can easily copy-paste your CMake command from Linux to Macos or Windows or viceversa without having to modify this flag explicitly.

Since there is already platform-dependent ON/OFF values for many flags, I claim that this should be the mechanism of 'quick build' and everything else should be hard-failing in case of conflicts since you are being explicit of what you set ON or OFF.

[hageboeck]

I think this hotfix suggestion is not helpful. The user likely wanted image support.

[ferdymercury]

The hotfix suggestion was thought as a kind of partial backward compatibility. It's a DROP-IN replacement of whatever was automatic before.

Before: set(asimage OFF CACHE
Now: consider adding -Dasimage=OFF

But more than happy to remove if that full change of behavior is encouraged.

[pcanal]

In contrast with the cocoa case, asimage default to ON and thus we are now requiring that a user that does -Dx11=OFF on linux must also disable all the dependent packages.

I personally find that annoying (there is no way to know before hand what all the dependent package of x11 are) but I can understand the simplification it brings, so if we must make those simplification, we still must make it easy to disable. (However this is really a case that showcase the fact that the simplification we are going for is actually making life harder for our users - eg. if I understood correctly disabling x11 is now a 2 stage process :( ).

[ferdymercury]

eg. if I understood correctly disabling x11 is now a 2 stage process :(

On the other hand, this is also what this PR is about. A user might be thinking that he does not need x11, so he sets that OFF, but then he gets error that asimage needs it. So he might set x11 back again ON because he needs "asimage" but didn't know that it depended on x11.

From a user-friendly point of view, a think this is a better behavior than silently disabling asimage=OFF.

From an expert developer point of view it might be a bit annoying, but in my opinion it's better to simplify, and later if one has a workflow of a 2-stage process that really needs to be optimized into 1-stage, it could be added in a follow-up PR provided that that addition does not resurface the bug that I am trying to fix here.

Better to have a pedantic-but-clearly-ruled 2-stage process for setting things x11 to OFF than to have a buggy process that ignores the user telling explictly to set something OFF or ON due to cache handling.