Show HN: Cross-platform dependency manager using bash and cmake

[ihnorton]

CMake already has decent support for dependency building through External Projects:

http://www.kitware.com/media/html/BuildingExternalProjectsWi...

There are a number of issues/annoyances with the mechanism, especially when working with local modifications, but nothing to make me eager to add the anguish of bash+CMake onto the existing toil of CMake.

(Arguably this also bootstraps a build environment, whereas CMake requires itself and an SDK in order to bootstrap, but at the point where a build environment needs to be scripted/reproducible containerization seems preferable)

[txutxu]

I ask from the ignorance, no pun intended.

Is there a good reason to insert 30 lines of license repetition, in each script of between 4 and 10 lines of total code?

I see it as a maintenance/developer-usability burden (specially if the license is at the _beginning_ of each file).

It is not under the license of the project, if the license is not in each file?

[mulle_nat]

That's just something I learned to do as an employee and so far didn't bother to question it.

[sdsykes]

Shell scripts do run on many platforms, but it's pretty ugly to code anything non trivial in.

[mulle_nat]

I thought it was pretty much impossible :) But since I started using [ShellCheck](https://www.shellcheck.net) together with [Sublime Edit](https://www.sublimetext.com/) I find shell programming "not too bad".

[radarsat1]

Only thing worse is CMake XD

[TickleSteve]

This feels like its solving the wrong problem, package-management is effectively a version-control problem.

We already have our source in version-control.... we just need a way of updating and maintaining a repository with external dependencies.

Do any such tools exist?

[chriswarbo]

I think Nix does/comes close to what you're after.

Nix 'packages' are just text files describing the build/install process, so they can be version controlled (e.g. there's a big repo at https://github.com/nixos/nixpkgs ).

Dependencies, build environments, etc. are fully specified by the package and isolated from each other, and there is an emphasis on reproducibility, so building/installing a particular package should always give the same results. (This isn't enforced, but a non-reproducible package is considered buggy, and there are tools to check if a package can be reproduced)

Nix packages themselves can reference external dependencies, like git repos and URLs, and usually provide a fixed checksum to compare the output against; if it doesn't match, the build is aborted. Wrappers/translators are also available to integrate with other package manager ecosystems, e.g. cabal/hackage for Haskell packages.

Results are cached locally (packages are only built once, until they get garbage collected) and remotely (if a build server has already built a package, you can fetch it from there instead).

For development environments, you can write a Nix package for your project then run the 'nix-shell' command to enter its build environment (i.e. all dependencies available, environment variables set, etc.)

[mulle_nat]

You want something which grabs source off other repositories and puts it inside your source tree and you want to version control all of it ?

I would not do that. I would fork the repositories I wanted and tag them along with your version. (mulle-bootstrap tag comes to mind :))

The embedding could be done with .bootstrap/embedded_repositories, which may or may not fit the bill.

[kozikow]

It works ok for me with docker images. It only works for languages storing dependencies in the environment (e.g. python), so it won't work as well for C++.

I can download any docker image. Docker image contains all external dependencies and I can inspect those dependencies.

I assign a version to each Dockerfile. Docker image version is in the source control. Image with each version is stored in docker image registry. Version bump triggers update of all packages (either system level or language packages). This lets me revert external dependencies to state from any point in time. Or check out any commit from source control and run it in the same state as it was running in prod at that time.

[radarsat1]

I think you're describing Homebrew. Actually whenever I'm building and installing something in ~/.local (which I do fairly frequently if I don't install it via apt-get, I'm not a /usr/local fan), I wish I were using something like Homebrew. Just something to manage whats in ~/.local, so I can remove things one package at a time. It'd be nice to have a lightweight version of checkinstall for non-root usage, for example.

[sirn]

You mean something like git submodules or git subtree[2]?

[1]: https://git-scm.com/book/en/v2/Git-Tools-Submodules

[2]: https://developer.atlassian.com/blog/2015/05/the-power-of-gi...

[octo_t]

package management is not version control. it is release control and the two concepts are different in their semantics.

[grive]

It can be used for that. You can configure the tag you want to fetch and build if the repository is version-controlled, effectively allowing you to follow an external project: update your local settings when bumping your requirements, and it should follow along.

[frumiousirc]

> Do any such tools exist?

One such tool:

https://github.com/LLNL/spack

[darkarmani]

Why not conda?

[mulle_nat]

Conda seems to deal with binary packages only. Solves a different problem.