
Cget: cmake package retrieval - pfultz2
https://github.com/pfultz2/cget
======
msbarnett
There's also CMake hunter, which covers the same problem space:
[https://github.com/ruslo/hunter](https://github.com/ruslo/hunter), with no
external dependency on python packages.

~~~
ndesaulniers
Damn, someone beat me to it. I knew Cmake's ExternalProject had a lot of
hidden potential!

I still think there's more that can be done with convention over
configuration, but not every package will switch to a new convention until
shown the benefit, even then...but Rome wasn't built in a day.

------
awinter-py
If C wants to remain competitive against up-and-coming systems languages in
the next 5 years (ahem rust), we need something like this. Half of the
packages in any linux distro would be straight-C packages in a sane universe.

I understand the counterargument that 'C compiles to every architecture' and
that's the key to its persistence, but hard-to-use library importing is such a
high bar for new developers to learn a system. All the new talent is going to
use what's easy.

~~~
striking
If you use Arch Linux, you get CMake files and headers for every library you
can install, built right into the package, as well as all the dependencies
you'll need for those packages.

C/C++ with CMake is honestly a joy. It's really wonderful. The issue is that
it's not the most popular thing to use right now. The hype train has wandered
off into the realms of JS, Go, and Rust. A lot of money goes into super-
convenient tooling for these newly relevant languages. So perhaps I've made it
clearer as to why C is less popular now.

~~~
klodolph
I've been using CMake off and on for years now, including recently. I feel no
joy using it. The syntax is ridiculous, the semantics are worse, and the
documentation is poor, even in 2016. It gets the job done, but it is a royal
pain in the butt. Whenever feasible, I'll use something else. These days, that
usually means writing a quick build script generator in Python. I've been
around for a while, so I remember using a lot of different build tools, from
monstrosities like autotools (which has good points), hand-written makefiles,
to "modern" designs like Jam, SCons, NAnt. CMake is basically the least usable
of all of these (except autotools), but at the same time it is the only one
which solves the desired task.

I wouldn't say that it's just a matter of money and popularity. C and C++ are
both quite popular these days. The problem is that the tooling is so different
between platforms. You want to build a shared library? Hah, the process is
quite different on Windows, and there are non-trivial differences between OS X
and Linux too. You need to change your header files on Windows depending on
whether the library is static or dynamic, and you even need to worry about
things like "who calls free()" because as soon as you make a DLL you can't be
sure that the person calling your code has the same malloc that you do.

With JS, Go, and Rust, the toolchain is identical on all platforms, there are
no header files, et cetera.

We've had decades to try and make C tooling nice and easy, and it simply
hasn't happened, despite the language's overwhelming popularity. The most
usable solution we've really come up with is writing C on your favorite Linux
distro, where you can just apt-get whatever you want and pkg-config it into
your build system. But once you want to build on OS X, you get to choose
between the insanity of Homebrew or the insanity of building your own
packages. On Windows, things are even harder, because suddenly all the shell
scripts that propped up your build system stop working.

Your experience on Arch just reflects the reality of cross-platform
development: it's awesome if you can avoid it. I do most of my development on
a Linux system as well and I can reasonably call it a "joy" right up to the
point when I need to finish the Windows and OS X ports. I don't think that you
can truly experience the horrors of CMake if you stick to Linux. Heck, on
Linux, you can hand-write makefiles fairly reasonably, if you know what you're
doing.

~~~
spriggan3
On Windows I was rather successful with developing C apps with msys2 which
comes with a Posix envirronment and pacman package manager. Most source that
use posix compliant apis compile on windows and mingw provides a few handy
adapters. It's obviously not going to run docker containers but it's really
handy, I was successful compiling quite a lot of c projects from scratch,
including some Gtk3 apps.

~~~
klodolph
Unfortunately, that won't work for me. Compiling with MSC is a requirement,
for various reasons.

------
flohofwoe
It would be nice if the README would mention how this compares to cmake's
builtin ExternalProject module, which at first glance offers similar
functionality
([https://cmake.org/cmake/help/v3.5/module/ExternalProject.htm...](https://cmake.org/cmake/help/v3.5/module/ExternalProject.html))

~~~
pfultz2
I don't think ExternalProject manages the packages. For example, cget won't
install the package again if its already installed.

------
icholy
I really like this. Kind of reminds me of
[https://github.com/clibs/clib](https://github.com/clibs/clib).

------
tbrock
Even C++'s de-facto package manager is too painful to write in C++? Haha I
kid, I kid.

~~~
pfultz2
I actually used python to make distribution easier. Otherwise, I would need to
write Debian/RPM packages for linux, update homebrew for the mac, and windows
installer for windows. So with python I just create one pypi package. It helps
save time, since this is entirely a volunteer effort. Perhaps in the future,
this could be written to run natively.

