# from David Golden
# on Saturday 27 October 2007 13:15:
>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/
If the Build.PL file is generated by the publisher, the install M::B
version doesn't matter *so much* -- it just has to be verified by the
Build.PL.
If it does matter, then configure_requires is absolutely required, which
is also true of MakeMaker.
A generated Build.PL can force/check configure_requires, etc (or at
least bail-out in the presence of an out-of-date toolchain.)
>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.
It only works if the bundler is aware of any bugs that they have bundled
and is available to do a re-release. The Module::Install model falls
down at the first dependency by an absentee author who isn't available
to roll a re-release to fix any bundled critical bugs (e.g. on a given
platform, etc.)
An autogenerated Build.PL and/or configure_requires will reduce the
amount of bundled code (you bundle only what is needed to check/ensure
a compatible toolchain), which reduces the chance of bundled bugs.
>> 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.
How long-term do you want it to be? The aggregate of short-term fixes
is going to eventually cause many Build.PL files to get arbitrarily
(and ad-hoc) complicated.
--Eric
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
