Currently `buildPerlPackage` prefixes the Perl version to the package's
`pname`, which results in `nix run` not being able to work for any
packages build with it out of the box. This commit corrects that and
phases out the ability to set `name` directly, as well as refactors the
code to not require `cleanedAttrs`.
Because perl packages are prefixed with the perl version, it means that
the `lib.getExe` heuristic will never point to the binary name. So we
provide the meta.mainProgram that overrides that, using the original
pname or parsed name. It's not perfect but should yield better results
already.
This reverts commit d0bad145f5.
We don't need this any more, because the generated timestamps are
always set to 1970-01-01.
Reverting this will mean we get man pages for perl programs for free,
because those are generally part of the `install' target.
This involved:
* Installing miniperl as $dev/bin/perl
* Setting miniperl to take INC from
lib/perl5/{site_perl/,}cross_perl/${version} as well as
lib/perl5/{site_perl/,}/${version}/${runtimeArch}, in that
order. miniperl taking from runtimeArch is not really correct, but
it works in some pure-perl cases (e.g. Config.pm) and can be
overridden with the cross_perl variant.
* Installing perl-cross's stubs into
$dev/lib/perl5/cross_perl/${version}
* Patching MakeMaker.pm to gracefully degrade (very slightly) if B.pm
can't be loaded, which it can't in cross-compilation.
* Passing the right build-time and runtime perls to Makefile.PL
This continues #23374, which always kept around both attributes, by
always including both propagated files: `propgated-native-build-inputs`
and `propagated-build-inputs`. `nativePkgs` and `crossPkgs` are still
defined as before, however, so this change should only barely
observable.
This is an incremental step to fully keeping the dependencies separate
in all cases.
... after auto-removing some kinds of files by default.
In some cases I let them be removed and in others I let them be put into
$docdev. That was more due to general indecisiveness on this question
than any reasons in the particular cases.
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
packages. Turns out that those packages set INSTALLDIRS=perl, so we
override it to INSTALLDIRS=site.
svn path=/nixpkgs/branches/stdenv-updates/; revision=15251
WTF is that the Perl module installation path suddenly has changed
from $out/lib/site_perl to $out/lib/perl5/site_perl. Investigating...
svn path=/nixpkgs/branches/stdenv-updates/; revision=15241
* Put the fix for Perl modules that install in the wrong location
($out/lib instead of $out/lib/site_perl) in the generic Perl
builder.
svn path=/nixpkgs/trunk/; revision=14051
to the propagated build inputs as a convenience to people who want
to install Perl packages into their user environments.
svn path=/nixpkgs/trunk/; revision=8278
* Remove explicit setting of PERL5LIB.
* Use the generic Perl builder for the BerkeleyDB and XML::Parser
modules.
* Prefix all names of Perl modules with `perl-' (in the generic Perl
builder).
svn path=/nixpkgs/trunk/; revision=2365
* MythTV: the setup program works :-).
* Added XmlTV. This requires a huge number of Perl modules, so...
* Added a generic builder for Perl modules. I'm lazy so the modules
are defined directly in all-packages-generic.nix. The generic
builder also patches Perl scripts to include a hard-coded Perl
module search path (i.e., similar to an RPATH in ELF executables).
svn path=/nixpkgs/trunk/; revision=2083
