Conan v2 usage

[friendlyanon]

The generated build instructions and CI workflow aren't compatible with Conan v2.

Hoping @SpaceIm can chip in here with an example that shows how to use conanfile.txt with the new CMake generators.

[SpaceIm]

I don't know whether it's fully compliant with conan v2, but this workflow should work with modern conan generators.

In project root folder:

• conanfile.txt

  [requires]
  foo/x.y.z
  bar/u.v.w
  
  [generators]
  CMakeToolchain
  CMakeDeps

• CMakeLists.txt: nothing special

Release build:

conan install . -if build -s build_type=Release
cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=build/conan_toolchain.cmake
cmake --build build --config Release

When using another generator that the compiler default one, don't forget to set tools.cmake.cmaketoolchain:generator in global.conf file of .conan folder (located in home dir by default), since the toolchain file may be slightly different. It can also be passed to conan install command.

For a really robust workflow when there are build requirements, VirtualBuildEnv generator should be added, and generated script executed (after conan install, and before cmake configuration & build).

[friendlyanon]

Thanks for the quick response!

I'm also interested in having multiple profiles for the install command. I have seen a few examples make use of multiple -p:... arguments.

Code that is of interest here:

• HACKING document for developers and contributors:

https://github.com/friendlyanon/cmake-init/blob/778a7e1ee5da846ee287e1a84148355d0a2c331f/cmake-init/templates/common/HACKING.md#L85-L96

• Code in CI to setup Conan:

https://github.com/friendlyanon/cmake-init/blob/778a7e1ee5da846ee287e1a84148355d0a2c331f/cmake-init/templates/common/.github/workflows/ci.yml#L58-L62

https://github.com/friendlyanon/cmake-init/blob/778a7e1ee5da846ee287e1a84148355d0a2c331f/cmake-init/templates/common/.github/workflows/ci.yml#L98-L102

https://github.com/friendlyanon/cmake-init/blob/778a7e1ee5da846ee287e1a84148355d0a2c331f/cmake-init/templates/common/.github/workflows/ci.yml#L152-L160

• Generators used in conanfile.txt:

https://github.com/friendlyanon/cmake-init/blob/778a7e1ee5da846ee287e1a84148355d0a2c331f/cmake-init/templates/common/conanfile.txt#L8-L11

The new VirtualRunEnv generator is also broken I think, because it only generates one kind of scripts to setup the environment variables. On Windows, it only generates a powershell script. What does one do with that when cmd is currently in use? How about Bash on Windows? virtualrunenv satisfies every usecase.

[SpaceIm]

I'm also interested in having multiple profiles for the install command. I have seen a few examples make use of multiple -p:... arguments.

It's 2 profiles. AFAIK, in conan v2, 2 profiles will always be used under the hood.

Just add -pr:b build_profile -pr:h host_profile to conan install command (or hardcode it in global.conf). With 2 profiles, conan uses the new dependency graph model which is more robust. Moreover, it's also the only reliable approach while cross-building with conan.

The new VirtualRunEnv generator is also broken I think, because it only generates one kind of scripts to setup the environment variables. On Windows, it only generates a powershell script. What does one do with that when cmd is currently in use? How about Bash on Windows? virtualrunenv satisfies every usecase.

That's true, VirtualRunEnv lacks .bat currently. But virtualrunenv doesn't satisfy every usecase, since it doesn't contain specific env vars of libraries required at runtime (it's unusual, but there are few libraries like this).

[friendlyanon]

I see. Is it safe to just auto-detect the initial profile and use that for both contexts? I guess since the target platform is the host platform in the general case, the answer will be yes, but just making sure.

That's true, VirtualRunEnv lacks .bat currently.

I don't think it would hurt to generate all 3 flavors of scripts regardless of the current platform.

[SpaceIm]

I see. Is it safe to just auto-detect the initial profile and use that for both contexts? I guess since the target platform is the host platform in the general case, the answer will be yes, but just making sure.

For native build yes. If it was working with 1 profile, it should be fine to pass the same profile to build & host context.

That's true, VirtualRunEnv lacks .bat currently.

I don't think it would hurt to generate all 3 flavors of scripts regardless of the current platform.

I agree. https://github.com/conan-io/conan/issues/10900 is asking for shell script on Windows for example.

[friendlyanon]

I have made the Conan template closer to being v2 compatible with https://github.com/friendlyanon/cmake-init/commit/7a0efe0f8ec2c817ff4f44aa83c3cdd274e9424f

I have also fixed things to conan<2 in the pip install commands https://github.com/friendlyanon/cmake-init/commit/a67bb1da8a89f833caceb3587013b3aa49695fe1

Do you see anything that could be done better here for now?

[friendlyanon]

This was fixed by ec13c2d3923c185075af92eabc15d88b7933769f (#88)