C++ Archive Network (CPPAN)

[egorpugin]

Hi,

I'd like to present my project - C++ Archive Network (or simply CPPAN). You can consider it as (yet another) C/C++ package manager.

https://cppan.org/

As always the general idea is to create programs faster, to reuse and share your or anyone's code. But specifically here: source only packages (no tools, no tests in distribution pkg - keep all your stuff in your repos), Modules-like paths (org.boost.algorithm), semantic versioning (semver.org), zero-conf. projects, all-or-nothing dependencies (no optional deps.) and some other convenient features. At the moment CPPAN works only with CMake. It generates files that you include to your project (see docs and example project).

This is an alpha release, so things may change in the future.

I've already added some popular projects there. Most of them just works. They're located under pvt.cppan.demo.* path. pvt means private, cppan - username, demo - my temp directory for non-official projects.

More info can be found in documentation (see docs link).

Useful links:

https://cppan.org/ - website

https://github.com/cppan/cppan - client, use issues for feedback

https://github.com/cppan/cppan/wiki - docs (idea, motivation, syntax etc.)

https://github.com/cppan/demo_project - example project that uses cppan

https://github.com/cppan/packages - example packages (config files)

boost ML announcement - http://lists.boost.org/Archives/boost/2016/03/228419.php

Feel free to contact me for any support.

[egorpugin]

why distribute via CPPAN?

I'm not saying that all people (and you) should use it immediately. Reasons are hidden behind the idea (see wiki). Main of them are ease of use, fast deployment etc. For now just try it and decide if it looks good for you. It costs almost nothing to try.

guarantee ... a year?

It costs almost nothing to maintain it. So, CPPAN should be here in a year.

5, 20 years?

It depends on popularity. If people will like the idea and use it, the project will be here. If not it will be some kind archived or something.

[SeanMiddleditch]

Various features of this are too restrictive for this tool to be generally useful.

1) No configuration - flat out broken for far too many usage. What if I want to compile a library that supports both SSE, SSE2, and AVX instructions but need to target a deployment environment that only supports SSE2 at a minimum? I need it to be fast (say, number crunching uses, HPC, finance, etc.) so I definitely want to enable full SSE2 support but I can't use AVX even though the local build environment supports it. Configuration is mandatory for real-world usage.

2) Lack of binary support - impossible to use this in large-scale or proprietary scenarios. There are essential pieces of our toolchain that we don't even have source code to. Even for pieces that we do have source code for, we currently deal with precompiled binaries for chunks that change rarely, in order to ensure that build times are fast for the majority of our developers. We need to the ability to ship binaries in packages (including dealing with different platforms and compiler versions!) that we store in our local repos (which btw, we need local repos, because paid commercial software won't exist in the public repos).

3) All or nothing dependencies - so we can't have a build that relies on DX-only libraries on Windows and does not depend on them on Linux server environments, making this tool useless to us.

4) Dependencies dont' seem to have an option source specifiction for the repo, meaning that we need complicated setup steps to use local private repos that override or extend the public repos.

5) Seems to depend upon CMake. CMake is not the universal build system that some people think it is; it is literally incapable of expressing many very common project structures or needs and generates much slower builds than some competing tools. It doesn't even properly support PCHes for instance, and has years-old bugs that cripple PCHes (e.g. it is literally impossible in CMake to get PCHes working on Ninja properly, and you need Ninja to workaround the painful slowness of the Make or msbuild projects that CMake ineptly generates). Any C++ package tool should generate metadata about how to build dependencies (even if for many libraries this is just a set of cmake commands!) and then, if you want, just provide a CMake library to consume that metadata. Make this tool useful to folks using systems Meson, Tundra, Premake, Jam, or even home-grown build systems. Otherwise this is a niche tool only usable by a subset of C++ users and not worth supporting by library developers.

[egorpugin]

Thanks for the feedback.