[Nix-dev] Accepting -jX on builds / wild idea / RAM usage ...?

Marc Weber marco-oweber at gmx.de
Wed Apr 1 17:07:51 CEST 2009


> PS: I have this wild idea of making a front end for Nix that reads a Makefile
> and basically converts it to a Nix expression - that is, every Make rule becomes
> a derivation.  Then you get all the parallelism you want and it would still be
> pure.  Or conversely, if your Makefile isn't pure (e.g. if build actions
> interfere with each other), it would deterministically fail.  As an added bonus,
> you would never have to write another "make clean" rule :-)

*shrug* .. How many inodes can you use on ext3 ? ;-)
So basically every .o file will get it's own store path?
I think there would be way to many o files..

I remember wxwidgets or such can build one .o file per function so that
the resulting binaries get as small as possible...

The idea is nice. It even makes sens for plugins for Eclipse, gimp etc.

I also think that gc time would increase very much.

But basically you're right: It doesn't matter wether you have

/nix/store/XXXXX0/lib/foo.o
/nix/store/XXXXX0/lib/foo2.o
/nix/store/XXXXX0/lib/foo3.o

or

/nix/store/XXXXX_1/lib/foo.o
/nix/store/XXXXX_2/lib/foo2.o
/nix/store/XXXXX_3/lib/foo3.o

How much will the nix-env time increase when building .drv files?
The nice dependency graphics will be garbage then as well, won't they?

If you use nix for some time and occasionally build yet another package
don't you end up using a lot of different glibcs ? Each of those shared
files is about 100MB.. Am I right that they start consuming quite some
memory?

What is the best way to prevent this?
forcing all users to reinstall their packages?
(That's the best and only way to get security updates as well..)

Marc Weber



More information about the nix-dev mailing list