Clean up and improve Cling's C++ header search

[hahnjo]

Clang's search for the standard C++ headers is complex, up to messy. It is a combination of build-time decisions in interpreter/cling/lib/Interpreter/CMakeLists.txt and runtime searches in interpreter/cling/lib/Interpreter/CIFactory.cpp. Below I'm listing a number of things I noticed, and I think it would be worth it to clean up this business:

• [ ] Let's start with the obvious: CLING_CXX_PATH and CLING_CXX_HEADERS are declared as options in interpreter/cling/lib/Interpreter/CMakeLists.txt. This gives them a type of BOOL instead of STRING (or maybe FILEPATH for CLING_CXX_PATH?).
• [ ] If these variables are not set by the user, the build system starts to make some guesses. These choices are not FORCEd back into the CACHE, so it will be re-computed on every CMake invocation.
• [ ] The code for determining CLING_CXX_PATH has a large section dealing with ccache and distcc, which can only be taken if users set the environment variable CXX="ccache g++". Since CMake 3.4, it is recommended to instead use CMAKE_CXX_COMPILER_LAUNCHER=ccache, or ROOT's ccache=ON, so this may be obsolete?

• [ ] The header lookup is inconsistent between the build system and the CIFactory: The messages during configuration suggest that the order is

  1. Determined directories of C++ headers, or if not found
  2. Invocation of the compiler's full path, or as a fallback
  3. Invocation of the compiler's relative path.

  I think this matches the initial implementation, but it's not true anymore since commit afabc3b63885427251fd69b4aeda887bae35a289 switched to asking the compiler in the PATH first, to address a problem report from CMS.

• [ ] It also appears that the default guess from the build system is to either set the compiler's full path or its relative path. This is potentially problematic because changing the PATH could make the interpreter pick up a different compiler, even though it could still ask the existing full path. It's also inconsistent with respect to the previous point because a compiler in PATH takes precedence over the directories determined at build time, while a compiler outside is asked last. Incidentally, this is exactly what seems to "save" CMS right now.

I actually started working on cleaning this up, but stopped when I discovered the problem report from CMS. I think what we need to have first is a proper discussion how we want things to work, and then implement that in a clean way.

[Axel-Naumann]

Before I digest and even start thinking: thank you ❤️ for starting this!

[eguiraud]

It seems that one instance of problem 4 caused problems for dask+htcondor+lxbatch: https://mattermost.web.cern.ch/root/pl/dou6tb5mofnitgxoqs9d8t6x4w