> What do people think? I think both (1) and (2) are going to suffer from architecture dependency problems, amplified by recursion.
I also think that blindly using a newer version of something without knowing if it's compatible with the bundled one is asking for trouble. But that's more a call to make sure a compatibility assurance mechanism is implemented, rather than saying don't do it. Adam K 2009/9/9 David Golden <xda...@gmail.com>: > Having looked at latest.pm (c.f. inc/latest.pm in the M::B source) I > have to say that I like it. How about 'newest.pm' as an alternate > name? (Apologies to rgs and ex::newest) > > Getting the dwimmery to work is a bigger issue. There's a > quick-and-dirty way and there's a correct way. (And probably options > in between.) > > (1) Quick and dirty -- for whatever needs to be bundled, recursively > copy everything from the current perl library path into the right > directory in inc/ (e.g. Module/Build.pm and Module/Build/* into > inc/inc_Module-Build) > > (2) Correct -- for each configure_requires, use CPAN(PLUS) (as defined > by the cpan_client property) to download the appropriate distribution > from CPAN and install into inc/ directories. All 'requires' > dependencies of the configure_requires must be processed similarly. > If a minimum perl prerequisite is defined, any of these modules > satisfied by core modules in the minimum perl can be skipped. (And > anything that installs an arch-specific component is a fatal error.) > > I'm tempted to do #1 just to prove the concept and get going, but it's > fragile and won't generalize, so I don't think it's a long term > solution. > > I thought about using packlists, but that only works for modules > installed from CPAN -- falling back to using the core packlist winds > up being just a variation of #1 above. > > What do people think? > > -- David >
