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
