4 ms·

Cget: cmake package retrieval

49 points by pfultz2 11y ago

flohofwoe 11y ago
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.html https://cmake.org/cmake/help/v3.5/module/ExternalProject.htm...)
- _wmd 11y ago
  ExternalProject is for the build itself to pull down dependencies, this looks more end-user (or end-dev) orientated
- pfultz2 11y ago
  I don't think ExternalProject manages the packages. For example, cget won't install the package again if its already installed.
icholy 11y ago
I really like this. Kind of reminds me of https://github.com/clibs/clib https://github.com/clibs/clib.
msbarnett 11y ago
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 11y ago
  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.
tbrock 11y ago
Even C++'s de-facto package manager is too painful to write in C++? Haha I kid, I kid.
- pfultz2 11y ago
  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.
- boris 11y ago
  Or not: https://build2.org https://build2.org
awinter-py 11y ago
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.
- davexunit 11y ago
  That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I've written distribution packages for a lot of free software, and the ol' ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. This is a really bad regression in software development. edit: I should note that the ./configure && make style of building a la Autotools is not C specific. I've seen other projects written in other languages use it and building their software is just as easy as a C project.
  - msbarnett 11y ago
    > ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.
    - davexunit 11y ago

49 points by pfultz2 11y ago

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.html https://cmake.org/cmake/help/v3.5/module/ExternalProject.htm...)

_wmd 11y ago
ExternalProject is for the build itself to pull down dependencies, this looks more end-user (or end-dev) orientated
pfultz2 11y ago
I don't think ExternalProject manages the packages. For example, cget won't install the package again if its already installed.

icholy 11y ago

I really like this. Kind of reminds me of https://github.com/clibs/clib https://github.com/clibs/clib.

msbarnett 11y ago

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 11y ago
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.

tbrock 11y ago

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

pfultz2 11y ago
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.
boris 11y ago
Or not: https://build2.org https://build2.org

awinter-py 11y ago

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.

davexunit 11y ago
That's funny, because I think C libraries and applications are, by and large, much easier to build and install than software written in any other language. I've written distribution packages for a lot of free software, and the ol' ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. This is a really bad regression in software development. edit: I should note that the ./configure && make style of building a la Autotools is not C specific. I've seen other projects written in other languages use it and building their software is just as easy as a C project.
- msbarnett 11y ago
  > ./configure && make && make install dance rarely gives me problems, unlike all of these "modern" build systems that are also language-specific package managers that do not even have the concept of a configure phase. ./configure && make && make install is wonderfully simple -- iff your system already has all of the package's dependencies installed. Otherwise you're left to manually track down ./configure && make && make install every dependency, and all of their dependencies, etc. In reality nobody does this, and system package managers are imperfectly providing for C/C++ what language-specific, cross-platform package managers are providing for the communities of Rust, Ruby, et al. Consequently the C/C++ community is more balkanized/less integrated across platforms.
  - davexunit 11y ago