>Hi, > >On 09/11/2011 06:45 PM, Michael Raskin wrote: > >> +x@{builderDefsPackage >> + , ...}: >> +builderDefsPackage >> +(a : >> +let >> + helperArgNames = ["stdenv" "fetchurl" "builderDefsPackage"] ++ >> + []; >(snip) > >Could you stick to the standard way of writing packages? That is, > > { stdenv, fetchurl }: > > stdenv.mkDerivation { > name = "libmodplug-0.8.8.4"; > > src = fetchurl { ... }; > > meta = ...; > } > >That style is easier to read, shorter, uses fewer strange idioms >(‘helperArgNames’?), is better documented, and easier to maintain by
helperArguments reduce code duplication: all standard packages list most of their arguments twice - as buildInputs and as arguments. Substantially editing this list becomes very annoying quickly. >others (because it is the standard notation). It is also unpredictable w.r.t. shell variable expansion (a few packages where I encountered it seemed impossible to write with setup.sh without simply writing a big nice builder.sh), it lacks a few predefined things that cannot be added without causing full rebuild.. >The purported advantage of builderDefs (making it easier to customise >build phases etc.) I haven't really seen in practice — stdenv's >setup.sh has plenty of customisation mechanisms. It has weak mechanisms of post-modification: when I commit a tarball version and actually use VCS-trunk version I need to add something to preConfigure of the package. Of course, its use is usually in user configuration. Also, there are a few expressions that use topic-specific buildPhases. The simplest example is about fonts. _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev