In article <200909291436.56429.enoba...@gmail.com>, Eric Wilhelm <enoba...@gmail.com> wrote:
> >Can't @INC also be stored in _build/config? > > That seems like it could make a mess of things. Storing it in Build > addresses the process disconnect between Build.PL and later actions. > That has some DWIM to it which is already somewhat fragile. Maybe that Well, I'd just store the extra libs in Build i _build/config and leave it at that without changing any other MB code. If I resume(), I can query the config and decide on my own how to handle it. Ideally, I'd like to know everything about the setup as I can from config. However, I'm assuming that config is rewritten whenever anyone runs Build.PL. If they run it with a different environment, things change but that's not MB's fault. > So you're running Build.PL in a different process, it does a > "use lib 'inc'", and then you want resume() to deal with that? If so, > it's probably doable, but hasn't been done. Well, inc is this particular problem, but I have another similar issue where a module creates a temporary directory for libraries that it only needs for its build. Note that I don't want inc in @INC unless Build.PL put it there. > How did you get past this bit in resume()? > > eval "require $build_class; 1" or > die "Failed to re-load '$build_class': $@"; Well, that bit is the problem. If I got past that I wouldn't have a probem. :)
