This required a fairly sweeping change to calculation of install paths.
Old way: Generate default install paths from config and store them
in the object properties during object creation. User modifications are
made directly to these object properties. The problem is in the timing.
Creation of defaults need to happen 'late' after any --config options are
processed, but this was overwriting any custom install paths restored from
_build (which happens "early")
New way: Default install paths are generated "on demand" based on whatever
config values are in force and are not stored in the object. Accessors for all
the install path properties now merge custom install paths in object
properties with the generated defaults on the fly. Among other things, this
allows config values to be changed programatically after object construction
and change the resulting install paths.
There is a subtle semantic change in that setting an install path to "undef"
stores that in the object properties. This ensures the generated default
is masked, giving an "undef" result. (The old way deleted the install path
from the object properties.) I think the end result is the same -- asking
for a "deleted" path returns an undef value.
Special thanks to Thorben Jaendling for writing a new test file to help me
confirm the bug and the subsequent fix.
git-svn-id: http://svn.perl.org/modules/Module-Build/trunk@13208 50811bd7-b8ce-0310-adc1-d9db26280581