Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 4039
Status: resolved
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: chris [...] clotho.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.20
Fixed in: (no value)



Subject: Surprising 'Build clean' side effect in copied project directory
This one took a long time for me to figure out... Under specific circumstances, 'Build clean' (or any Build actions for that matter) can operate in the wrong directory. Try this: % cd MyProject % perl Build.PL % Build % cd .. % cp -r MyProject MySimilarProject % cd MySimilarProject % Build clean This scenario arises because I'm in the habit of starting a new module by copying an older, similar one and editing instead of starting fresh with h2xs. The clean action in the example above runs in the "MyProject" directory, which is unexpected. This is because the $start_dir is recorded in the Build file. The principle of least surprise suggests that Build should work like MakeMaker in that it works on the current directory, not on an absolute directory. A workaround is to always 'Build realclean' in a project directory before copying or moving it. A possible solution is to desist from storing the $start_dir and instead have Build chdir() to it's own location by looking at $0. A similar issue would arise in the @INC array stored in Build, in which "." is translated into an absolute path. In this case, a workaround would be to leave the @INC paths unchanged. The relevant line of code is: $_ = File::Spec->rel2abs($_); in the print_build_script() method.
Perhaps it should do as it does with the perl interpreter ($^X), and simply warn/die if you're running it from a different directory than it think you should be. -Ken
This is now fixed in CVS, and will be included in the next release.