Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
Well, the idea is that:
1. If Build.PL is used, then Module::Build is likely the main script,
and Module::Build::Compat has probably generated the Makefile.PL,
which means it's either an ExtUtils::MakeMaker-style Makefile.PL
(traditional) or a simple stub that loads Module::Build to do the work
(passthrough).
In the case of the module using EUMM, not everything can be
represented in the PREREQ_PM field that EUMM offers. This means that
things like recommended modules are either dropped from the
Makefile.PL or that they are set as required instead of simply
recommended.
I'm not sure about the implications of this, as further discussion
from gregoa and dam seems to indicate that it's not used for
determining dependency information.
However, when Build.PL is invoked, it provides nice hints like
"optional dependency Test::Without::Module not installed" which tells
us to add that to Build-Depends-Indep of debian/control
2. If only Makefile.PL is used, then it's a toss-up whether it's EUMM
or Module::Install. But either way the only choice is to run the
Makefile, so this is irrelevant. Similar goes for only Build.PL.
3. Module::Install was designed to be an extremely portable build
system. This means it's unlikely that someone will try to make a
passthrough Build.PL module which instead points to the Makefile.PL,
because Makefile.PL was the older standard anyway (before Build.PL
came along). As a result it's unlikely that a newer M::I installation
will have Build.PL pointing to Makefile.PL; it would simply not have
any Makefile.PL for compatibility purposes.
In conclusion, these 3 common scenarios form the basis of my argument
for switching the logic.
On Fri, May 8, 2009 at 12:59 AM, Ryan Niebur <ryanryan52@gmail.com> wrote:
> just a USE_BUILD_PL variable or something would be good enough
> imho. then we can choose. or if debhelper were to check if M:B:C is
> being used, and make a decision from that.
If such a variable existed on my system, I'd leave it permanently set
for the above mentioned reasons. As a result it seems like it'd be
better to patch upstream.
>
> --
> _________________________
> Ryan Niebur
> ryanryan52@gmail.com
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoDvBYACgkQMihv+PacasXrzgCfcgzZ+DfqSA922bGg1xLaFBvr
> gUMAnA7MoO7+WpizHp36CNgHMq5VAw57
> =Uoa3
> -----END PGP SIGNATURE-----
>
>
Here is what Joey Hess mentioned in a bug report from gregoa (#496157):
"Changing it to prefer Build.PL is dangerous, because:
* An unknown number of packages may be using dh and have both a
Makefile.PL and a Build.PL, and some subset of those may fail when the
Build.PL is used. No way to know w/o testing.
* A package may ship a Makefile that calls Build.PL, but also does other
things. Prefering Build.PL would break such a package. Maybe such
packages don't currently exist, but they could in future, and if the
change were made, they couldn't easily use dh.
Instead I think dh_auto_install should get an improved check for whether
a Makefile was generated by MakeMaker, and only do the prefix hack if
that is clearly the case."
However, as outlined above, I believe the second assertion is
incorrect - that a Makefile.PL would ever point to Build.PL. As it
stands, CPAN itself prefers Build.PL over Makefile.PL -- if
Module::Build is installed then Build.PL will be used; otherwise the
shell will ignore that file entirely and deal with Makefile.PL. That
is the reasoning between using a passthrough Makefile.PL.
Because ExtUtils::MakeMaker goes way back in Perl (it's really really
really old stuff), pretty much every installation of Perl will also
have EUMM. On the other hand, this is not so with M::B. So it stands
to reason that there would never be a Build.PL which pointed to a
Makefile.PL. This might change in the future, but I really doubt it.
Here are the options from a CPAN developers' point of view:
* Have only a Makefile.PL. Then CPAN will work perfectly and use that one.
* Have only a Build.PL. If Module::Build isn't installed then the
module will break completely.
* Have a Build.PL and Makefile.PL. If Module::Build is installed, then
Build.PL will be called directly; otherwise Makefile.PL's traditional
or passthrough script will be used. In the passthrough case,
Makefile.PL simply offers to download Module::Build and runs that to
do all the work instead.
On the other hand, the first point is very valid and correct. I have
no way of knowing whether it will break existing packages which have
been done with EUMM, so we need a gradual transition between EUMM and
M::B.
However, based on the above arguments, I think it's extremely unlikely
that Makefile.PL is the better maintained of the two, assuming they
both exist. The most likely scenario is that Makefile.PL is provided
for backward compatibility automatically by Module::Build::Compat.
Another point to consider is Gregor's point that this is really a bug
in Module::Build::Compat. However, I think we can fix this easily and
cleanly here (ie, no patches necessary to current dists), and apply
for a bugfix upstream.
I stand by my argument that Build.PL should be chosen over
Makefile.PL, and that one bug report I found offers nothing to say
otherwise. Perhaps I am missing something though, so I'd be happy to
hear what others have to say.
It is certainly a sign that the greybeards (dam, gregor :-)) don't
remember the exact reasoning behind it. It seems to imply that it's
been a cargo cult-ish thing, and that we can fix this process with no
ill effects.
What we might be able to do is use Ryan's idea in the interim -
providing an environment variable to do that stuff. In that case, the
pkg-perl team could do a trial run using that (or simply patch
debhelper locally for our machines) and see if we ever come across a
module that breaks due to that. If we try it for a few months with no
breakages then I think we have a much better argument to submit
upstream to Joey et al.
Cheers,
Jonathan
Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496157
Reply to: