Conan2 support

[jakeheke75]

Hi, Added support for Conan2 build. Thanks.

[Twon]

Hey Gianmario,

Thanks for the PR to add Conan 2 support! So I think I've seen this approach of conan profiles else where ;)

Nice to see you applying this elsewhere. A couple of things we've done in Morpheus which we might want to apply here too. The first is the .conanrc file which causes installation of profiles to be local to the repository and not global: https://github.com/Twon/Morpheus/blob/main/.conanrc. This will keep install profiles from poluting any global profiles.

The next issue is the choice between conanfile.txt vs conanfile.py. Effectively conanfile.py allows you to programmatically define how a conan target is packaged with specific logic to make choices over things like dependency (i.e. does behaviour on Windows and Linus differ) and so on. I originally chose the simpler conanfile.txt as I thought this was easier to understand for new-comers. Specifically, this approach is aimed at packaging a Conan package (which as an executable, not a library, this is never intended to do). So unless we require specifically to programmatically control the dependencies I think it probably easier to avoid the python conan file, but feel free to push back here if I've missed something.

Cheers, Antony

[jakeheke75]

Hey Gianmario,

Thanks for the PR to add Conan 2 support! So I think I've seen this approach of conan profiles else where ;)

Of course :smile: Obviously everything I did in this PR I learned it from you in Morpheus project.

Nice to see you applying this elsewhere. A couple of things we've done in Morpheus which we might want to apply here too. The first is the .conanrc file which causes installation of profiles to be local to the repository and not global: https://github.com/Twon/Morpheus/blob/main/.conanrc. This will keep install profiles from poluting any global profiles.

Sure! Didn't I include also the .conanrc file in the PR? :thinking:

The next issue is the choice between conanfile.txt vs conanfile.py. Effectively conanfile.py allows you to programmatically define how a conan target is packaged with specific logic to make choices over things like dependency (i.e. does behaviour on Windows and Linus differ) and so on. I originally chose the simpler conanfile.txt as I thought this was easier to understand for new-comers. Specifically, this approach is aimed at packaging a Conan package (which as an executable, not a library, this is never intended to do). So unless we require specifically to programmatically control the dependencies I think it probably easier to avoid the python conan file, but feel free to push back here if I've missed something.

You right. I was totally missing this point. Now that you pointed it out I understand that I misunderstood the usage of conanfile.py. Now it's clear and I agree with you. I will switch back to a simplified version of conanfile.txt. Thank you for taking the time to explain this.

[Twon]

Build failures were caused by upgrading boost from 1.78 to boost 1.83. In boost 1.81 boost beast migrated their string view implementation from boost::detail::basic_string_view to boost::core::basic_string_view which does not support the to_string method.

[Twon]

Looks like the CI hanging was called by invoking the conanbuild file as a powershell script not at bat script.

[Twon]

Upstream Clang15 fix required for CCAPI dependency: https://github.com/profitviews/ccapi/pull/1

[jakeheke75]

Thanks @jakeheke75 the Conan 2 upgrade. All working now and looking good!

Thank you for all the hard work :pray: