The plugin refuses to read neither my .zshenv file in which I set CONAN_USER_HOME nor the same environment variable set in CLion

[AbrilRBS]

To be clear, I am sidestepping the conan-clion-plugin by entering the commands that fail manually. The above command is executed by the plugin - which does not specify the build profile - and fails with the same error of compiler incompatibility with compile options. I am using conan manually, instead of relying on the plugin, because the plugin refuses to read neither my .zshenv file in which I set CONAN_USER_HOME nor the same environment variable set in CLion (but this is besides the point right now).

Originally written by @maichmueller in conan-io/conan#14870

[jcar87]

There are two issues here.

The issue mentioned conan-io/conan#14870, seems to be possible related to the conan profile being informative, but not imperative, that is:

• informative: "I am telling Conan which compiled is being used"
• imperative: "I am telling Conan to instruct dependencies to be built with this compiler"

The profiles can be imperative if the tools.build:compiler_executables is defined as a [conf], or if other fallbacks are used (.e.g [buildenv] or CC,CXX env vars).

As for the environment variables not being read by Conan, which is invoked by Cmake, which is invoked by CLion, this will depend on the OS. On macOS for example, I believe desktop GUI apps do not inherit environment variables because they're launched by launchctl in isolation - could be wrong.

On Linux, this will depend on specific factors https://superuser.com/questions/709535/zsh-where-to-place-environment-variable-so-that-launched-application-can-pick-i
like whether the env var sare defined in the right shell profile file, whether they are exported, and how the shell is set up to launch X and all child processes.

We'd need more details, like OS, linux distro, desktop mananger, etc - and trace it back from there. Also we need to investigate whether CLion itself removes any env vars before calling CMake.

But if the CMake process itself is picking up the environment variables, so should Conan when it is invoked by the dependency provider. We should verify which Env vars CMake is exposed to, or if the ones we expect are defined.

Another note: CONAN_USER_HOME has no effect in Conan 2.0 (which is used by CMake-Conan) - Conan 2.0 requires CONAN_HOME.

I'd defined CONAN_HOME in .zshenv, restart, launch CLion, add the following to CMakeLists.xt and then see if CMake itself sees it:

message("Conan home env var: $ENV{CONAN_HOME}")