On 10/27/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > I think we should take this as an opportunity to consider how many > redundancies are "suggested" for Build.PL "for the sake of > compatibility." > > http://www.nntp.perl.org/group/perl.module.build/2007/09/msg902.html > > The publishing author is (hopefully) using an up-to-date Module::Build. > The version on the installation machine doesn't matter quite so much.
I think the version on the installation machine matters a lot. I don't think that's going to be better unless Module::Build goes the Module::Install route and starts bundling a minimal installer in inc/ > I would rather just assume proper configure_requires support, but > yeah -- that's not going to be universal for five years or something, > right? (Barring an aggressively self-updating cpan client and a > scheduled breakage of the index files forcing an update to said > self-updating client.) I think configure_requires is a long-term plan, not a short-term fix. If you want a couple hours of "fun", go build a stock perl 5.00505 in a separate directory on a machine with another version of perl already installed somewhere and then try to upgrade it with Bundle::CPAN. Until some versions of perl are declared to be "no longer supported" then these backwards compatibility issues will continue to dog us. Frankly, I'm coming around to the Module::Install inc/ idea as the way to work around these toolchain constraints -- e.g. Devel::CheckLib. It's a hack, but it's a hack that seems to work. David
