
Conan – C/C++ package manager - ingve
https://www.conan.io/
======
ctstover
Trying to be constructive, I would say this needs to zoom out a few layers and
make a case for what concepts it is trying to address.

The primary means to distribute open source software is via source code.
Automagical technologies to assemble all the source code for a dependency
tree, and/or automagical technologies to fetch precompiled dependency trees
with curated options, versions, component granularities, etc are extremely
non-trivial problems. To date the only examples of this done with a measure of
effectiveness are actually entire operating system distributions backed by
software like apt, yum, pkg-src, etc.

Primarily because of the total failure in this regard of windows and osx,
individual languages themselves starting advancing ecosystem centric
dependency management with files retrievable from servers hosted on line. At
best, this style strategy solves some of the problems some of the time, and at
worst breaks the ability to make things even work the old way - ie manual
download, assembly, and compilation of source code dependency trees.

In the context of largely portable, interpreted code, this sort of thing is at
plausible. In the context of native code with multi-dimensional matrices of
OS/Compiler/libc/versions/flags/phases of the moon, the notion of a repository
of precompiled binaries to even enough cover "common cases" to be thought of
as a language level feature.

In the case of source dependency management, exposing the information about
where and how things are installed and reachable for use in the build
environment of the foreground project is hard enough, and trying to be able to
hold cross platform build recipes of some sort is literally the creation of
yet another operating system. Take homebrew for example.

Perhaps some sort of unification wrapper over apt and pkg-config is a thought,
but honestly can't even guess what problems can be addressed with something
like this.

In all seriousness the only cross platform solution maintaining build
environments is to just host all builds on linux, use mingw64 and osxcross
along with apt or yum + regular pkg-config, git, etc.

This looks like someone who thinks things like pip and gem make sense trying
to overlay that paradigm to a broader scope. Or maybe I'm just too old to "get
it". Please clue me in?

~~~
TheCoreh
> To date the only examples of this done with a measure of effectiveness are
> actually entire operating system distributions backed by software like apt,
> yum, pkg-src, etc.

npm seems to handle this just fine for both JS and native (c++) node modules
via gyp, and it's officially supported on at least three platforms (Windows,
Linux, OS X) using 3 different compilers AFAIK (microsoft c/c++, gcc and clang
respectively). Granted, node enforces specific conventions for packaging and
lookup (package.json and node_modules), but there's no reason similar
conventions can't be created for C/C++ modules, even if they're more
complicated due to language specific complexity (dynamic vs static linking).
Mantaining packages up to date for a lot of open source projects could be done
by a sufficiently dedicated community.

~~~
haberman
> npm seems to handle this just fine for both JS and native (c++) node modules
> via gyp

Could you describe this in a bit more detail? Does gyp (in the context of npm)
build the binaries at install time, or is it a repository of a bunch of pre-
built artifacts?

In my experience of installing npm packages, it doesn't seem like it's
building native extensions at install time, but it's hard to say for sure.

~~~
TheCoreh
It does build them on install time, if a suitable compiler is available. A
classic example is the `ws` module (WebSockets), when you install that you'll
normally see the build log for its native dependencies on the npm output:

    
    
      $ npm install ws
      
      > bufferutil@1.2.1 install /Users/coreh/Projects/test/node_modules/bufferutil
      > node-gyp rebuild
      
        CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
        SOLINK_MODULE(target) Release/bufferutil.node
      
      > utf-8-validate@1.2.1 install /Users/coreh/Projects/test/node_modules/utf-8-validate
      > node-gyp rebuild
      
        CXX(target) Release/obj.target/validation/src/validation.o
        SOLINK_MODULE(target) Release/validation.node
      /Users/coreh/Projects/test
      └─┬ ws@0.8.1 
        ├─┬ bufferutil@1.2.1 
        │ ├── bindings@1.2.1 
        │ └── nan@2.1.0 
        ├── options@0.0.6 
        ├── ultron@1.0.2 
        └── utf-8-validate@1.2.1

------
pathsjs
This is great! I really, really hope it takes off! C is in dire need of a
package manager that can handle dependencies well. OS package managers do not
allow multiple versions, and it is extremely difficult to get reproducible
builds, because every project has available whatever is installed globally on
your machine.

I have used sbt, nimble, leiningen, maven, npm, cargo, conda, and while each
of those has its own issues, I would take any of them when working with C.

I have tried biicode, that was showing some promise, but it seems it is not
gaining traction...

~~~
ross-harrison
This looks a lot like biicode. Lasote was big contributor to that as well.

It's not clear from their docs, but if it requires a seperate repo like
biicode then I think it is also doomed. A package manager can't be intrusive,
ideally including a single file in the root of a project (see bower, npm,
rubygems).

Their example project uses a couple special made repos, which is concerning.
I'd rather see the main project repos, with configuration added.

~~~
drodri
Not really. Already hosted packages like Boost, Zlib, OpenSSL, ZMQ, Protobuf
are packaged and hosted without changing a single line of their respective
build, and with just a single conanfile.py to define the packaging. The build
systems of those libraries are heterogenous: Cmake, B2, perl+nmake... The
build system is just wrapped by the conanfile.py. Those conanfiles can be also
in a separate repository and retrieve sources from any origin as github, so
not intrusive at all.

------
ambrop7
Yawn, another language-specific package manager.

If only there was something like a universal package manager, that provides a
generic but powerful package-management platform. Something where package
specifications look just like expressions in a purely-functional programming
language, and the package manager implicitly understands the complete
dependency graph, including all inputs to all build actions.

Something like Nix.

~~~
pcwalton
> Yawn, another language-specific package manager.

People have been bemoaning language-specific package managers in favor of
(Nix/apt-get/yum/Homebrew/MacPorts) for years now, and again and again
developers keep flocking to them, despite the supposedly-superior alternatives
being readily available. Rather than continuing to complain about this state
of affairs, perhaps we should try to figure out why language package managers
are so successful.

~~~
pnt12
I can think of at least 2 advantages.

1\. only packaging once, opposed to making a .deb, a .rpm and so on.

2\. as soon as its in the language repo, it's available everywhere. Even if I
make an apt-get package, I'd have to wait for Ubuntu/Debian/others to include
it in their repos. Or I'd have to host a ppa, requiring users to search for it
and add it to their package manager. RPM fusion and AUR simplify that, but it
still seems hard to have your own packages on .deb systems.

~~~
sparkie
Also because people are complacent with something that works well _most_ of
the time, but not all of the time. (where _most_ applies only if you're
running the latest stable Ubuntu)

------
jupp0r
From reading the documentation it's not really obvious to me how conan handles
ABI incompatibilities resulting from different C++ standard versions. I could
create a package that would pass a std::list to the package user. Depending on
the C++ standard compiler setting the user would expect objects of different
size -> undefined behavior.

~~~
lasote
compiler and compiler.version are settings. conan generates different packages
when settings change. So Conan will download the package that matches with
your settings. In case, for example, of a header only library, package
mantainer can "disable" compiler and compiler.version settings, so the package
will be the same for all compilers. What do you think? Do you think it should
work?

~~~
ctstover
What would the schema be for storing compiler settings? Those would be of
almost arbitrary complexity. Maybe if you combined the os/compiler
name/compiler version/settings/deps versions, etc into a an alphabetized
spaced delimited string and hashed that or something. idk...

~~~
prodigal_erik
The majority of compiler options don't affect calling convention or class
layout, so shouldn't make object files incompatible. They could be whitelisted
and omitted.

~~~
roel_v
But preproc flags will. How does this tool deal with that? Just recompiles on
every request for a certain config? Why is this better than a repo that has
crossplatform-buildable code that is downloaded and compiled locally? Like
nuget but cross platform?

------
knughit
C-Onan, the C package manager written to scratch the author's own itch?

------
nikolay
So, it's like clib [0] by TJ Holowaychuk [1]?

[0] [https://github.com/clibs/clib](https://github.com/clibs/clib)

[1] [https://medium.com/@tjholowaychuk/introducing-
clib-b32e6e769...](https://medium.com/@tjholowaychuk/introducing-
clib-b32e6e769cb3)

Edit: No, it is not.

~~~
warmwaffles
Love clib

------
mahtuag
Situation:

I install Python locally (w/o the OS-level package manager which doesn't have
Python 3.5 yet) and would like to install the SciPy stack which depends on a
bunch of C libraries only supplied by the Linux distro I am using.

What I'd Like:

Something like npm's package.json or pip's requirements.txt where I can
declare the semantically versioned C/C++ dependencies of a project; doing
conan install should fetch and install those dependencies so that pip can (as
a future feature) invoke this before installing the SciPy stack and not pause
a dozen times complaining about a missing dev dependency.

Does conan solve this problem ? If no, what alternatives do I have ?

Depending on OS-supplied libraries is a royal pain because they are almost
always outdated.

I'm all for one idiomatic package manager per language/platform (as it is
today for a lot of recent ones) which simplifies dependency management
significantly.

------
cbd1984
Is it for C or C++?

~~~
eXpl0it3r
Both

