
Show HN: Cross-platform dependency manager using bash and cmake - mulle_nat
https://github.com/mulle-nat/mulle-bootstrap
======
ihnorton
CMake already has decent support for dependency building through External
Projects:

[http://www.kitware.com/media/html/BuildingExternalProjectsWi...](http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)

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.

~~~
txutxu
I remember being told the same in a project/company in Holland, Europe. Never
have been told again.

Maybe being strict worldwide (as soon as something is published to internet),
or as soon as there is Intellectual Property Agreement, they are required
lines.

I use to avoid them in each single file for personal projects, unless it's a
convention (for example in perl, license in POD format at the end of the CPAN
class, is a community practice).

~~~
Iv
My suggestion is to put a single line copyright with the year in every file,
like

// (c) 2016 txutxu

and a license inside the project. The default copyright license protects you
from unwanted copies.

But when it comes to IP rights, a lot of practices are actually voodoo
legalities: people do them out of habit and paranoia, not because it has ever
been useful in court.

------
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](https://www.shellcheck.net))
together with [Sublime
Edit]([https://www.sublimetext.com/](https://www.sublimetext.com/)) I find
shell programming "not too bad".

------
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](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.)

~~~
TickleSteve
...similar to spack...

Isn't this effectively equivalent to version-controlling a shell script that
contains a set of 'curls' or 'clones'?

What I had in mind would be more invisible and self-contained within the VCS.

It would effectively be a meta-VCS.

------
darkarmani
Why not conda?

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

