Eric Wilhelm wrote: > # from Michael G Schwern > # on Tuesday 16 October 2007 11:57: > >>> Isn't the real issue simply that we shouldn't automatically install >>> into a location which is masked by an older M::B? It's not a >>> heuristic if you can check the other three trees and find a .pm >>> file. Maybe the answer just involves ExtUtils::Install? >> That, too, is guessing. It's guessing at the user's intent. Maybe >> they want to shadow. For example... >> >> perl Build.PL --install_base=~ > > That example doesn't involve 'core', 'site', or 'vendor' paths. > >> There's another way to look at this. This is a general problem >> effecting all dual-lived Perl modules. MB is no different and does >> not have to add to its burden by trying to solve this problem alone >> and special casing its install. > > Yes. I think that's what Ken was going for with the "installdirs > => 'auto'" setting. As far as determining user intent, do we actually > have a problem there? The --installdirs flag is able to set this > parameter.
I really don't like this idea. Part of the problem with MakeMaker was the unpredictability of the install location and it's trying to guess based on the existing installation. --install_base restored predictability. Now this returns to unpredictability and guessing. All to add a convenience feature for a very narrow group of module authors which already has an O(1) solution. > The one caveat with checking qw(core site vendor) would be to choose the > one which actually has the highest precedent in @INC. I'm not seeing > where that is determined in Config.pm though. Should we just examine > @INC (which could have been changed in this process) or is there > something in Config which should answer this? You're going to have to match up @INC with installprivlib and installarchlib to identify the core install directories. -- Robrt: People can't win Schwern: No, but they can riot after the game.
