[question] Lmod CPATH vs Conan -isystem

[nextsilicon-itay-bookstein]

What is your question?

Hi!

I'm using Lmod / EasyBuild, and it appears to provide include directories via the CPATH environment variable. According to the GCC docs this is equivalent to injecting -I arguments.
Conan, on the other hand, ends up injecting -isystem arguments on the command-line (at least via the CMake generator).

When I build grpc, which depends on openssl, if the OpenSSL Lmod module is loaded (and therefore present on CPATH), its includes 'win out' and cause the grpc build to not use the correct headers provided by Conan. This is because -I 'wins' over -isystem. When there's a version mismatch e.g. Lmod OpenSSL/1.1 vs Conan OpenSSL/3.3.2, I get link errors as a result. (Mercifully, this is much better than ODR violations... :) )

From what I see in the above GCC docs, the other Environment Variables inject -isystem and not -I. This is a bit weird to me - why couple the 'language independent' environment variable to extra behavior like -I and not -isystem? I realize this is a question for GCC... but I'm not sure what to do here.

What's the expectation of Conan's behavior with respect to the presence of CPATH?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[nextsilicon-itay-bookstein]

Cross-reference easybuilders/easybuild-framework#3331

[memsharded]

Hi @nextsilicon-itay-bookstein

Thanks for your question.

Conan, on the other hand, ends up injecting -isystem arguments on the command-line (at least via the CMake generator).

Conan does not really inject anything, it doesn't even tell CMake via the generator code what to do. The CMakeDeps generator will create some IMPORTED targets, assign the interface include directories to it, and those will be found by find_package() and the targets linked with target_link_libraries(). And CMake will decide what flags to use, if -I or -isystem (I think it has some toggles to select or control that), but Conan does not play a role there at all.

What's the expectation of Conan's behavior with respect to the presence of CPATH?

Basically none. Conan does not read, manage, define or do anything at all with the CPATH environment variable.
Conan is not a build system and then leverages as much as possible the underlying build systems.
It is true that for some build system integrations, like integrating with autotools, Conan does generate environment variables, in this case the include directories will be mapped as CXXFLAGS like -I<path>.

But this doesn't seem connected to the issues you are seeing, it seems that you are relying on the CMake generators (CMakeDeps), isn't it?

[nextsilicon-itay-bookstein]

I am relying on the CMake generators, yes. The fact that Lmod/easybuild injects the CPATH variable and that it's present during the build of grpc causes the Lmod/easybuild openssl headers to be taken over the openssl headers that Conan provides for grpc out of the Conan cache. They get overridden even though the Conan openssl is specified on the command-line and not via an environment variable, because the preference as I understand it is:

1. -I provided on the CLI
2. -I injected via env vars (CPATH)
3. -isystem provided on the CLI
4. -isystem injected via env vars (C_INCLUDE_PATH, CPLUS_INCLUDE_PATH)