cmake-conan VS POCO

-- The CXX compiler identification is GNU 9.4.0-- The C compiler identification is GNU 9.4.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Setting build type to 'RelWithDebInfo' as none was specified. -- /usr/local/bin/ccache found and enabled -- Downloading conan.cmake from https://github.com/conan-io/cmake-conan -- Conan: Adding cci remote repository (https://center.conan.io) verify ssl (True) usage: conan remote [-h] [-v [V]] {add,auth,disable,enable,list,list-users,login,logout,remove,rename,set-user,update} ... conan remote: error: unrecognized arguments: https://center.conan.io True ERROR: Exiting with code: 2 CMake Error at build/conan.cmake:858 (message): Conan remote failed='2' Call Stack (most recent call first): build/_deps/_project_options-src/src/Conan.cmake:20 (conan_add_remote) build/_deps/_project_options-src/src/Index.cmake:182 (run_conan) build/_deps/_project_options-src/src/DynamicProjectOptions.cmake:132 (project_options) CMakeLists.txt:79 (dynamic_project_options)-- Configuring incomplete, errors occurred! See also "/home/user/Desktop/bitwyre/trading/intermediaries/cram_cpp_v3/build/CMakeFiles/CMakeOutput.log".

Some pure conan options, there's a 2.0 super early developer preview for https://github.com/conan-io/cmake-conan/tree/develop2

https://github.com/conan-io/cmake-conan/tree/develop2 might interest you :) we love feedback

I totally agree with you. Have a look at the new cmake-conan integration using Dependency Provider in the develop2 branch : https://github.com/conan-io/cmake-conan/tree/develop2

I've always used conan together with the conan cmake module

using conan from within cmake you can use this https://github.com/conan-io/cmake-conan, or just write your own execute process way of calling it . https://cmake.org/cmake/help/latest/command/execute_process.html

See https://github.com/conan-io/cmake-conan for a neat wrapper that I use in almost all my projects

I always wanted to try to use cmake-conan so I could let Conan grab all packages but have a neat cmake script being in charge of what gets built when. Also, this would allow me to easily switch between CMake fetchcontent and Conan packages that may or may not be stashed automatically on a local Artifactory server. Secondly, since now all build requirements are stashed on a server and binary reproducible, you could concider adding icecream and ccache into the mix. (Try running a node one of your buildservers for massive speadups with icecream) This however does require a reproducible build environment (by configure script) which conan again is really good in.

You can also look into Poco https://pocoproject.org/

I can't say enough good stuff about POCO for this type of work - when I first got my teams using it we used to joke that POCO was what Boost wants to be when it grows up. And nlohmann/json - cracking library for working with JSON in C++.

We use https://github.com/pocoproject/poco in most projects, very easy to set up a http listener

Did someone used Poco's Net Library to create a Rest Api? Poco Project

But CLion is so slow. Tested with Poco C++ standard build (https://pocoproject.org/). Moving around with Go To Definition takes sometimes up to 20 seconds if file is first touched. Using 'back' and 'forward' delays for 1-2 seconds.

Yes, you need NetSSL - take a look at find_package(Poco REQUIRED COMPONENTS ... NetSSL) requires an aditional find_package(OpenSSL) since poco-10.

poco (portable components) https://pocoproject.org/

Many of the necessary fixes do end up getting pushed upstream, though, thinking especially of stuff like converting CMake projects to use the GNUInstallDirs standard, so there is a benefit to the strictness work that extends beyond even just the Nix community itself.

Of course, sometimes those kinds of changes just never get merged, for a variety of well-understood open-sourcey reasons, eg: https://github.com/pocoproject/poco/pull/3105