feat: support conan 2

[FeignClaims]

Support conan 2 by replacing the old conan script with conan_provider.cmake.

Todo:

• customizing conan profiles and invocation of conan install.

Current design questions:

• The new conan_provider.cmake script for conan 2 requires CMake 2.24+. Is it acceptable to set cmake_minimum_required(VERSION 3.24) for the whole project_options?
• The cmake script for conan 2 is incompatible with conan 1. Should I keep the conan 1 function or replace it?

Close #212

[aminya]

Can you keep the old version? Maybe we can specify the version in the Enable_conan flag (with the default being 1).
The version can be also detected from a CLI call to Conan.

[FeignClaims]

Can you keep the old version? Maybe we can specify the version in the Enable_conan flag (with the default being 1). The version can be also detected from a CLI call to Conan.

Ok.

[FeignClaims]

Ready to merge.

I finally choose to add a new function run_conan2() to support conan 2.

• As for the cmake 3.24+ requirement, run_conan2() will detect it when it is actually invoked.
• As for users who enable conan 1 but actually want conan 2 (or vise versa), run_conan2() and run_conan() will detect the version of conan and send a FATAL_ERROR message if the version dosen't match.

The cmake script of conan 2 uses a different logic to make itself almost transparent to cmake (by cmake -B build -S . -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=conan_provider.cmake, it can require no modification of CMakeLists.txt).

In order to integration, run_conan2 must be invoked before project(...), but conan 1 is required to run after project(...). So there's no way (AFAIK) to generalize them to one function.

---

As for tests, I failed to figure out how to keep both conan 1 and conan 2 tests, so I install conan 2 manually and use conan 2 in all tests. Help wanted.

[FeignClaims]

So there's no way (AFAIK) to generalize them to one function.

It occurs to me there's a way to generalize them: a function run_conan() which should be invoked before project(...). Then,

• If conan 1 is used, run_conan() registers a invocation. When project_options(...) is invoked, it checks the registration and actually calls _run_conan1() if it should.
• If conan 2 is used, run_conan() invokes _run_conan2().

This is somehow wired since conan 1 actually runs when project_options(...) is invoked.

Should I switch to use this generalized function or just separate them into different functions like now?

[aminya]

I like the idea of run_conan. Should we deprecate the Enable_conan option?

[FeignClaims]

Finished run_conan() and ready to merge.

Should we deprecate the Enable_conan option?

I removed it in documentation but kept t it in code for backward compability. A DEPRECATED_CALL option was added to distinguish the different behaviour of the interface, That is,

• run_conan() before project(...): supports both conan 1 and conan 2. The conan 1 follows the new conan 2 interface (the HOST_PROFILE、BUILD_PROFILE、INSTALL_ARGS in documentation).
• ENABLE_CONAN in project_options(...) after project(...): removed from documentation, only supports conan 1, messages a FATAL_ERROR if users enable it using conan 2.

[aminya]

Thanks a lot for your contribution! 💯