On Wed, 30 Mar 2011 18:57:28 +0200, Andreas J. Koenig
<andreas.koenig.7os6v...@franz.ak.mind.de> wrote:
On Wed, 30 Mar 2011 15:42:32 +0200, "Christian Walde" <mitha...@yahoo.de> said:
> Maybe sometime in the future i'll build a build_dir_reuse function
> that can do the same job without increasing ENV vars massively.
Good luck! David and I have tried hard but failed. You find the traces
of the failed experiment in the repository under CPAN/PERL5INC.pm. I do
not even remember the details.
I just pushed a first sketch of the base functionality to this commit in my
fork:
https://github.com/wchristian/cpanpm/commit/858dd51110fdbf7bb8bbaa73dc24a073ee1ae346
The reasoning behind this so far:
- At this time in execution we do not know yet what the build dir of the dist
were going to work on is.
- It is reasonable to assume that at any given time there will only be one test
running.
- The temp dir creation code of Distribution.pm is a mess and not easily
extracted, so before it could be used here, refactoring is necessary.
As such, the changes are as follows:
- If File::Copy::Recursive the old perl5lib-prepending mechanism is used.
- Otherwise $CPAN::META->{cachemgr}->dir.'/build_merge' is first deleted
entirely, then remade.
- File::Copy::Recursive is used to copy the contents of all arch and blib dirs
into build_merge.
- That dir is prepended to perl5lib.
The test suite of CPAN itself passes fine with this change and F::C::R
installed and i'll do some real life testing tomorrow, using dists that would
otherwise break on WinXP. (Hello Tapper::*!)
Otherwise, the hard part about this is now the bike-shedding and i REALLY hope
i'll get some feedback on this. Things i'm pondering:
- Should i make the effort to create a temp dir with a randomized name instead,
by factoring out the functionality in Distribution.pm?
- Would it be better to copy parts of F::C::R into CPAN itself?
- Is this fine as letting it pick up on F::C::R automatically, or should it
maybe become an o conf option?
- I really wonder what all little hooks and problems i missed.
Only remotely related:
- How open is CPAN.pm to pull requests that consist only of refactorings to
reduce the amount of code duplication?
--
With regards,
Christian Walde
