[Nix-dev] Nix as a build script for developers

[Marc Weber]

Excerpts from Sam Thursfield's message of Sun Oct 25 01:40:13 +0200 2009:
> Hi!
> I've just found out about Nix and I think its a very interesting
> project. Straight away it gave me an idea (and apologies if this has
> been mentioned before; I did do a search in the archives first): ..
> Since Nix can build packages from source, does anyone think it would
> be neat to use it as a replacement for complex build scripts, like
> GNOME's jhbuild?

I don't know jhbuild, so I can't comment on that.

> Nix would need a few obvious extra features:
> - svn/git/cvs in addition to fetchurl

You should also grep the nixpkgs repo.
Of course there is 
- fetchbzr
- fetchgit
- fetchsvn(ssh)
- fetchdarcs
- fetchcvs

But for daily updates I recommend you looking at my bleeding edge
implementation. It let's you run
run-nix-repository-manager-with-config --update xorg_group
and be done.

> - a way of specifying both a VC repo and tarball locations for a
> module in the same file
See comments about my bleeding edge implementation. I haven't had time
to implement yet. But it should be easy to do.

> - and a way for the user to specify what version of the module they
> want installing.
There are multiple ways. Your most approach hasn't been used extensively
because having multiple options also increases amount of build
combinations etc.
 
> - the ability to maintain and build modules from directories in the
> user's search tree, so they could hack on them and then install them

See nix-env -K (keep build directory). Note that you have to unset some
NIX_* env vars or change them to make nix no longer strip debugging
symbols.

Also have a look at repo nixpkgs file /pkgs/top-level/my-env/default.nix
It tries to capture the build environment used by nix so that you can
load it using  $loadEnv foobar where foobar defines a set of libraries
which are required by the package you're working on.

Eelco Dolstra even thought about using nix to control every single step
of a make file compilation process. However he never implemented it :-)

> - more vicious garbage collection, since there would be lots more new
> versions being installed
Not sure what you're talking about. Get to know nix first. Jump in and
start using it.

> - substitution of binary packages. Instead of building all 100 (which
> takes a LONG time on old PC's or on Windows) Nix could install most of
> the dependencies from binary packages. Unless you run a bleeding-edge
> distro, system packages are normally too old; for example, building
> gtk+ from git often needs the last unstable release of glib. Nix
> provides a nice way to satisfy this without (a) running an unstable
> version of a core library or (b) building the whole of glib
There is one drawback using nix:
A depends on B depends on C

If you change C you have to rebuild B and A. So some changes actually
requires a huge amount of rebuild. So you have to take care what you
change. So you can't just fix a shared lib in C without rebuilding B and
A.

> Anyway, this seems like a fair amount of work and jhbuild does the job
> fairly well, so I'm not going to cancel my weekend to start work on
s/weekend/weekends ? *kidding*

So may I just propose that you install nix, join #nixos on
irc.freenode.net. I bet nix can already do a lot for you.
You should at least get to know nix in such detail that you can answer
the question you asked yourself.

And yes you're right: If jhbuild already works well for you should
continue using it. The reason is that the main purpose of nix is
assembling packages so that they can be redistributed and build in a
very pure way. You want this for continuous integration etc.
But you don't always want this for developing.

You can also try to tell about a specific use case you'd like to solve.
We can help you finding a nix way.

You're welcome
Marc Weber