Open hwhsu1231 opened 2 years ago
I would really like this feature to be made official by conan.io folks and actively maintained, so it does not meet the same sudden end, as cmake-conan did.
Conan.io folks are breaking expected user space functionality far too often for our liking and this is forcing us to really consider switching away from conan as a package manager.
I would really like this feature to be made official by conan.io folks and actively maintained, so it does not meet the same sudden end, as cmake-conan did.
Conan.io folks are breaking expected user space functionality far too often for our liking and this is forcing us to really consider switching away from conan as a package manager.
Hi @saukijan,
Could you please provide more details on the breaking changes we made? Have you opened any issues with them?
Thanks
Hi @hwhsu1231, Thank you so much for all the effort put in that project. We don't have the resources currently to take the project as we are in the middle of the Conan 2.0 release but we will definitely have a look deeper when Conan 2.0 is out and we will try to do our best to provide a solution for users. Thanks!
sure @czoido, I opened issues both on conan-io and conan-center-index as well as contributed packages I also chimed in on existing issues, when relevant.
Regarding breaking changes, the artifactory migration comes to mind first. Sure it was not your fault, but it definitely was handled poorly. After that, the SSL certification issues, which caused the whole service outage, then pre v1.43 conan simply not working with the new conan-center, now this planned conan v2.0 changes and deprecation of cmake-conan and old cmake generators. It adds up and makes it harder than necessary to get conan adopted in-house as a standard tool, especially when we have to keep telling devs: "Oh it's a conan issue, we know. Wait for the next conan update that should fix it" - it erodes trust in the tool as a whole and trust is already hard to build up.
Change is always hard and painful, I get that, but asking devs to have to keep changing their workflow to make a package manager work simply is ridiculous, especially when it comes out of the blue (though this is more of a personal problem of not keeping up with conan blogs)
I understand that conan.io folks have a lot on their plate and that you feel like the whole community is trying to pull you in different and contradicting directions. Conan project looks really great and the idea of it is of great value to the C++ community as a whole, but this combative tone really paints a bad picture of conan.io, a simple "Thanks for your work, we will look into it later" instead would go much further.
I want to love conan and help it grow into the defacto C++ package manager, but this whole affair makes me second guess that desire.
@saukijan,
I wanted to aplogize if my tone seemed combatibe, It was not the intention at all. I really wanted to know If I you had some issues I could help you with. Also, thanks a lot for your kind words regarding Conan, we try to do our best and we are very sorry if things break from time to time, I know it can be very frustrating. Regarding this project, as I said to @hwhsu1231 in the previous comment we will listen to all users feedback and try to offer the best solution we can come with, but sadly that will be after Conan 2.0 as we don't have the resources now to tackle it.
Thanks a lot for your feedback.
Project Link
https://github.com/hwhsu1231/cmake-conan-setup
Introduction
Dear Conan Team,
This project is my Solution to the issue that I posted before:
I've already writen down the Motivation, Usage, Mechanism, Demonstration...etc in this project. Please take a look. First of all, it is required for
conan_cmake_install()
supporting--conf
argument in this project. See more details on this PR:However, this PR is not yet merged to the
master
branch even thedevelop
branch for now. So I have to prepare a modified version ofconan.cmake
in this project. Hope this PR can be merged as soon as possible. Otherwise, an error due to includingconan_toolchain.cmake
when using non-default CMake generators might occur. For example, using MSVC compilers with Ninja generator:Click to expand
```cmd F:\GitRepo\cmake-conan-setup>vcvarsall x64 ********************************************************************** ** Visual Studio 2019 Developer Command Prompt v16.11.19 ** Copyright (c) 2021 Microsoft Corporation ********************************************************************** [vcvarsall.bat] Environment initialized for: 'x64' F:\GitRepo\cmake-conan-setup>cmake --preset win32-msvc-x64-ninja-debug Preset CMake variables: CMAKE_BUILD_TYPE="Debug" CMAKE_CXX_COMPILER="cl.exe" CMAKE_C_COMPILER="cl.exe" CMAKE_INSTALL_PREFIX:PATH="F:/GitRepo/cmake-conan-setup/install/win32-msvc-x64-ninja-debug" CMAKE_PROJECT_INCLUDE_BEFORE="F:/GitRepo/cmake-conan-setup/cmake/conan-setup.cmake" -- Downloading conan.cmake from https://github.com/conan-io/cmake-conan -- The C compiler identification is MSVC 19.29.30146.0 -- The CXX compiler identification is MSVC 19.29.30146.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Conan: Detected VS runtime: MDd -- Conan: checking conan executable -- Conan: Found program C:/Python/Python310/Scripts/conan.exe -- Conan: Version found Conan version 1.53.0 -- Conan executing: C:/Python/Python310/Scripts/conan.exe install F:/GitRepo/cmake-conan-setup/conanfile.py --remote conancenter --install-folder F:/GitRepo/cmake-conan-setup/build/win32-msvc-x64-ninja-debug/conan-dependencies --output-folder F:/GitRepo/cmake-conan-setup/build/win32-msvc-x64-ninja-debug/conan-dependencies --build missing --settings arch=x86_64 --settings build_type=Debug --settings compiler=Visual Studio --settings compiler.version=16 --settings compiler.runtime=MDd Configuration: [settings] arch=x86_64 arch_build=x86_64 build_type=Debug compiler=Visual Studio compiler.runtime=MDd compiler.version=16 os=Windows os_build=Windows [options] [build_requires] [env] conanfile.py: Installing package Requirements cli11/2.2.0 from 'conancenter' - Cache eigen/3.3.9 from 'conancenter' - Cache fmt/8.1.1 from 'conancenter' - Cache Packages cli11/2.2.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache eigen/3.3.9:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache fmt/8.1.1:8ed2451fe8e6a2dd1b2f8bac3c035717ff9ddfa8 - Cache Installing (downloading, building) binaries... cli11/2.2.0: Already installed! eigen/3.3.9: Already installed! fmt/8.1.1: Already installed! conanfile.py: Generator txt created conanbuildinfo.txt conanfile.py: WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior conanfile.py: Generator 'CMakeToolchain' calling 'generate()' conanfile.py: Preset 'default' added to CMakePresets.json. Invoke it manually using 'cmake --preset default' conanfile.py: If your CMake version is not compatible with CMakePresets (<3.19) call cmake like: 'cmakeIt is because the default generator on Windows is Visual Studio generator. Therefore the
conan_toolchain.cmake
generated by CMakeToolchain will have the following two lines, which shouldn't be specified when using Ninja generator.Hope Conan Team take over this project
I'm willing to transfer this project if Conan Team thinks it is worth maintaining. Here are the reasons:
And my requests are:
Alternatively, if Conan Team wants to be collaborators of this project, then I can add them into this project.
If Conan Team has the willingness, please let me know. Thanks.
Haowei