
Build2 – A C++ Build Toolchain and Package Manager - beagle3
https://build2.org/
======
ryandrake
Ugh. Hate to be Debby Downer. I mean, nice effort, but one of the crappy
things about some of these newish languages is how each of them comes with
their own package manager baggage that is different from the package manager
that all the rest of your software is installed through.

So I have my Debian setup and I'm happily using apt to install all my
software. Now ruby comes along and I need some libraries and have to go and
install everything with gem. And I can't use apt to see what gems I have
installed and vice versa! Argh!!! Now I have to write some python code and
here comes pip... And node/npm... and on and on.

apt-get install libx11-dev is just fine for my C and C++ development needs,
thankyouverymuch. I don't see the value in yet another incompatible package
manager.

~~~
tyoverby
Let's say that you and I both create a library. You try to publish your C++
library to the standard debian repository, and I'll try to publish mine to
cpam, npm, pip, etc...

If you actually manage to get your library included, then we can compare how
long it takes to update your library.

~~~
Sanddancer
Systems like Debian, though, have the ability to add custom repositories. So
after the initial, possibly small package that just configures the
sources.list, everything's handled with all the other updates. That's
something that npm, etc, can't do.

~~~
pathsjs
Npm and many other package managers support custom repositories just fine

------
RcouF1uZ4gsC
Nice work. However, I think the C++ community is best served by standardizing
on CMake. It is widely used by many projects, and many IDEs natively support
it natively (for example Jetbrains Clion, and Microsoft Visual Studio 2017)

In addition, "modern CMake" is much better than classic CMake" and the project
is improving with such things like CMake server.

~~~
quacker
CMake is not a package manager or package repository, though. CMake can
discover libraries and it can build your code, but that assumes you've already
fetched a dependency somehow. Sure, you can use system package managers, but
these are different on every platform.

I've been writing a simple video game in C++ recently, using CMake to build. I
wrote a little bit of code that fetches the few libraries I need in order to
have a complete/deterministic build process that works on linux/windows/mac.
It lets me change versions (by specifying a new url to a source tarball).
Versioned dependency management is so typical and convenient in many other
languages and is such a pain in the butt with C++ because CMake is this thing
that's sort of good enough. But my CMake experience doesn't compare well at
all with maven, pip, gem, cargo, or even npm.

~~~
lantastic
Conan ([https://conan.io/](https://conan.io/)) tries to tackle the package
management for C/C++.

~~~
epage
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.

~~~
pjmlp
I dislike it is written in Python instead of C++.

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

~~~
Samathy
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.

~~~
pjmlp
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.

------
humanrebar
I've been by this page a few times. It's interesting to see work in this area,
but there are only 15 packages on cppget.org. Obvious ones (boost, protobuf,
folly, etc.) are missing from the list.

Is this still in some sort of alpha state with respect to new package
submissions? Or is nobody volunteering to maintain the missing packages?

------
jokoon
Any compiler already supporting some experimental version of modules?

If library devs could start trying those out, it might give it some
traction...

------
m-j-fox
I feel like the name bpkg is taken. BSD uses it and a search shows there's a
Bash package manager that calls itself bpkg also.

Maybe call it cpkg?

------
christianlefty
this is awesome we need the maven of cpp

~~~
dom0
> maven of cpp

Oh dear god no. Can we please have a way more sane manager than a maven of
cpp?

~~~
archgoon
What are the problems you encountered with maven (I've only used it a few
times)?

------
DonbunEf7
Why would I use this instead of Nix?

~~~
pfultz2
Last time I looked at Nix it had a problem with dealing with cross-
compilation. The problem is mainly that many packages still use autotools
which does not have a descriptive toolchain. Ultimately, it could provide a
descriptive toolchain and then map that toolchain to the different build
systems, which is similar to what cget does, but perhaps a separate tool to do
this could be helpful so this could be shared among different package
managers.

------
unix
why not use github for package repository?

~~~
seabrookmx
Do you mean git? Not sure what difference github makes over vanilla git in
this case..

GoLang kind of does this (via "go get") and it sucks for multiple reasons:

-you can only distribute packages as source, meaning you need to compile them yourself (this has pros and cons, but it would be nice to be able to distribute binaries if you want)

-your dependencies reference a commit hash, and unless you micromanage your dependencies and constantly look at the github repository's tags, you have no semantic versioning, making it a lot more likely you'll encounter breakages

-there's no way for your dependencies to specify dependencies, unless they're using git submodules (very few projects do), and even with submodules, you can't share dependencies across packages

The list goes on..

Git is for source control. Package managers offer a lot of different (and
awesome IMO) features. Lack of package management is one of my biggest gripes
with GoLang honestly.

