Greetings, Consider the emacs-23 package as an example, it has an optional ‘gtk’ argument we can set and is checked for null.
So in a config one might have something like (emacs23.override { gtk = gtk3; }) Unfortunately this means that one always has to build emacs themselves. It would be great if package maintainers could provide some default arguments with which Hydra will build. Continuing with the emacs23 example, both the GTK and no-GTK ways would be common so perhaps we could state something like meta { hydraBuildWays = [ ({ gtk = gtk3; }) ({ gtk = null; }) ]; }; For packages with more options and asserts, it would still work: meta { hydraBuildWays = [ ({ withSDL = false; withQt4 = true; }) ({ withSDL = false; withQt = true; }) ]; }; Consider a large package (say webkit) that someone took effort to provide configurable flags for but you're never going to use them because it's too much effort to build yourself. This would then build both of the above packages at least twice (3 times if the defaults up top are different) and whether the user wants emacs23 with or without GTK, they wouldn't have to build it themselves. It's a bit like building the Haskell libraries with profiling, without profiling, shared, …, except selectively. The package maintainers would be the ones responsible for deciding what's sensible: we don't want to build with every configuration of boolean flags possible but only the common ones. This is only an idea at this point but what do you think? Yes, there would be extra things to build by Hydra, can it afford it? I don't imagine the implementation would be extremely difficult but I don't have experience here. -- Mateusz K. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev