Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
Hi Gregor:
Thanks for your response.
It's somewhat surprising to me that these Perl module-specific things
are dealt with in a package that is out of our control (ie debhelper).
In that case, getting a bug fix submitted/discussed/dealt with might
not be worth the effort. However I think in the long term it can save
a lot of time. See some additional discussion I added below:
On Wed, May 6, 2009 at 4:42 PM, gregor herrmann <gregoa@debian.org> wrote:
> On Wed, 06 May 2009 10:31:54 -0400, Jonathan Yu wrote:
>
>> I've only got two responses, but it seems that at least two people
>> other than myself think it's worthwhile to revert the behaviour of
>> dh-make-perl to choose Build.PL before Makefile.PL. However, I do not
>> know the reasoning for changing this behaviour, so it is entirely
>> likely that I've missed something.
>
> Since quite some time dh-make-perl defaults to debhelper 7, so it
> just puts "dh build" in debian/rules which calls dh_auto_configure,
> which prefers Makefile.PL over Build.PL. So the change would need to
> happen in debhelper, not in dh-make-perl.
> (dh-make-perl's "old" (as in dh pre-7) debian/rules templates prefer
> Build.PL, IIRC.)
>
>> My argument for switching to Build.PL over Makefile.PL is thus: in
>> Module::Build modules that produce a Module::Build::Compat Makefile.PL
>> for compatibility, there is a Makefile left around even after the
>> cleanup happens. This looks like a bug in Module::Build::Compat not
>> adding Makefile in with its cleanup scripts, but nonetheless, it
>> sticks around and wreaks havoc until it's removed.
>
> M:B:C also creates the infamous .packlist files ...
>
>> If you do a 'debian/rules clean', it will run Build.PL's cleanup which
>> removes Build and all intermediate files, EXCEPT for the Makefile that
>> was generated.
>
> Well, seems like there are at least 2 bugs in M:B:C which should be
> fixed instead of worked around :)
You're correct here. But one thing that I neglected to mention in the
initial e-mail is that Makefile.PL (via EUMM or passthrough) cannot
handle the types of complex dependencies that Build.PL can. What I
mean by that is, M::B can handle "recommends" relationships.
On the other hand, Module::Install handles those relationships just fine.
If, however, both Build.PL and Makefile.PL are included in a
distribution, then more than likely it is a Build.PL base with either
a passthrough or traditional (generated by
Build.PL/Module::Build::Compat) EUMM Makefile.PL.
In this case, it means that Makefile.PL will not pick up things like
'suggests' and 'recommends' and 'conflicts'. On the other hand, these
can always be picked up by the debhelper scripts via META.yml. I,
however, don't know the source of that stuff for dh-make-perl.
>
>> For various reasons the general consensus seems to be to pick Build.PL
>> first, and fall back on Makefile.PL if unavailable.
>> I look forward to seeing what others have to say about this.
>
> Besides my notes above I have no strong opinion on which way to
> prefer ...
>
> Cheers,
> gregor
> --
> .''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
> : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/
> `. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
> `- NP: Paul McCartney & Wings: Eleanor Rigby/ Eleanor's Dream
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoB9hoACgkQOzKYnQDzz+RlqQCfTPeSZPOLc5E8SM5TRBPoAk6w
> uscAoK3Z37ZGJ3a/Ws7OeUtz7c0GMGq+
> =L/sy
> -----END PGP SIGNATURE-----
>
>
Reply to: