[Nix-dev] (Optionally) Build same package multiple ways on Hydra

Kirill Elagin kirelagin at gmail.com
Tue Jun 10 12:03:44 CEST 2014


That's a tough topic… https://github.com/NixOS/nixpkgs/issues/2021



--
Кирилл Елагин


On Tue, Jun 10, 2014 at 4:31 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> 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 at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140610/540fb6f9/attachment.html 


More information about the nix-dev mailing list