News for hackers. Stuff that matters.
Re:Build2 – A C++ Build Toolchain and Package Manager by epage on Thursday May 04, 2017 @09:36PM (#14270497)
While Conan still has some room to grow, I love the approach they take to package management for C++.

Too many C++ tools couple package management and build which increases their adoption cost and makes it more work to package third part packages. Conan takes the approach of managing dependencies and then giving your build system of choice the information it needs to access those dependencies via conan plugins. I think I had read that the author of Conan was involved in biicode and that the third party packaging problem is what inspired him to create Conan.

Some other cool things about conan

- Can be used for more than C++

- SCM independent

- Artifact caching

- Options allow clients to customize your package (creates distinct artifact)

- Scopes allow developers to modify your build (like conditional build steps so doesn't create a distinct artifact)

Some things I think can be improved

- Needs to separate out dependency lock file like Cargo or Poet

- Build tools need to be packaged in Conan for tracability / reproducibility

- Plugins are in Python which is heavy for deployment and has a large compatibility surface

- Easy to hit limits of declarative dependency files, being forced into implementing them in Python (see above)

- Project templates are hard coded.

Re:Build2 – A C++ Build Toolchain and Package Manager by pfultz2 on Friday May 05, 2017 @04:26AM (#14271922)
> Too many C++ tools couple package management and build

Conan does this too. If I follow the instructions to integrate cmake with conan, I would write something like this:

    include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
    conan_basic_setup(TARGETS)

    add_executable(timer timer.cpp)
    target_link_libraries(timer CONAN_PKG::Poco)
Which now couples my build with conan. If the user would like to pull down the dependencies without conan(ie using apt-get or manually installing them), the cmake build script will not work.

Package managers like cget[1] or conda[2] does not couple the build with the package manager. Cget is also serverless which is nice as it can install dependencies from anywhere(even directly from github with `cget install jgm/cmark`), however, you need to setup your own server hosting if you want to install binaries.

[1]:http://cget.readthedocs.io/en/latest/

[2]:https://conda.io/docs/intro.html

Re:Build2 – A C++ Build Toolchain and Package Manager by slezyr on Friday May 05, 2017 @05:02AM (#14272066)
> Which now couples my build with conan. If the user would like to pull down the dependencies without conan(ie using apt-get or manually installing them), the cmake build script will not work.

http://docs.conan.io/en/latest/integrations/cmake/find_packa...

Re:Build2 – A C++ Build Toolchain and Package Manager by pjmlp on Friday May 05, 2017 @01:09AM (#14271245)
I dislike it is written in Python instead of C++.

No need to force me to install Python just to run a build tool.

Re:Build2 – A C++ Build Toolchain and Package Manager by pfultz2 on Friday May 05, 2017 @04:32AM (#14271939)
The nice things about cget is that even though it uses python(which is mainly for easy distribution), the cget protocol only has a dependency on cmake. So cmake modulues like cmake-get[1] can install cget recipes directly in cmake without needing python installed.

[1]:https://github.com/pfultz2/cmake-get

Re:Build2 – A C++ Build Toolchain and Package Manager by Samathy on Friday May 05, 2017 @04:02AM (#14271838)
Python is a great solution to the problem as well as being installed on most Linux distros by default. Chances are devs would need for their other dev tools anyway even not on a Linux machine.
Re:Build2 – A C++ Build Toolchain and Package Manager by pjmlp on Friday May 05, 2017 @05:08AM (#14272082)
A build tool should be written in the same language as it is targeted for, no need for third party dependencies.

Many of us only install what we actually need, or what the IT department allows on our images.

I certainly don't want to open a IT ticket to get Python, just to be able to compile random package X.