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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
