Module::Build and custom install_path fixes

Reading time: 2 minutes

I just attempted a fix for the preservation of custom install_paths on resume() in Module::Build (RT#41166). This required a fairly sweeping change to calculation of install paths. If you do custom install_path work using Module::Build or set your own custom install path configuration, please test from the Module::Build svn trunk:

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.

Feedback from people who actually use this feature would be appreciated.

•      •      •

If you enjoyed this or have feedback, please let me know by or