Re: Dual-Build Modules (What to do if both Makefile.PL and Build.PL exist)
Okay, new question on all of this then.
Maybe what we can do is suggest that Build.PL be preferred over
Makefile.PL in the future with new modules. What needs to be done to
facilitate this? I don't know if there is a way other than to change
debhelper.
However, it would be nice to be able to do this, because it means we
can gradually fix the current modules on a case-by-case basis.
Is there a way we can design an upgrade path from Makefile.PL to
Build.PL that will not break current builds, but can facilitate a full
switch to Build.PL (where provided upstream, of course) in the distant
future?
I'm glad we've all got talking about this.
One more thing, from Michael Schwern (upstream maintainer of
ExtUtils::MakeMaker), quoted on
http://www.nntp.perl.org/group/perl.module-authors/2009/05/msg7531.html:
"I concur. If you can run the Build.PL, run it.
The Makefile.PL exists for compatibility only. It is not perfect, never was
intended to be and never will be. It may contain only a subset of the logic
in the Build.PL. It may not fully emulate a real Makefile.PL.
You can consider this definitive."
I hope that this is all sufficient reason to at least begin a gradual
transition. I'm not saying we should switch everything over
immediately, as that has the potential to cause lots of breakage (I
can't flat out say that Joey Hess' assertion that switching will break
existing packages is incorrect). So what I propose is that we try to
determine an upgrade path that will let us gradually move toward the
recommendation - Build.PL.
Another thing of note is that Adam Kennedy (maintainer of
Module::Install) has also chimed in, quoted on
http://www.nntp.perl.org/group/perl.module-authors/2009/05/msg7530.html:
"When both Makefile.PL and Build.PL exist, you should ALWAYS run the
Module::Build installation process ( perl Build.PL; perl Build; perl
Build test; and so on...) and ignore Makefile.PL.
The few old legacy modules with the pass-through Module::Install
Build.PL can safely be ignored. I hope soon to start chasing them down
and ensure they are all upgraded."
So maybe we can work on it over time :-). I want to minimize the
amount of problems this causes for everyone, as I know the FTP masters
and gregor are already quite overworked. On the other hand, this has
the potential to fix some problems down the line, particularly with
the 'traditional' generated Makefile.PL's that may not work as the
Build.PL intended. Bugs in Module::Build::Compat are likely to pop up
in the future, and the best way to avoid them and be completely
unaffected by them is to use the Build.PL in the first place.
So, about an upgrade path, does anyone have any ideas how we can go about this?
Cheers,
Jonathan
On Sat, May 9, 2009 at 7:35 PM, gregor herrmann <gregoa@debian.org> wrote:
> On Fri, 08 May 2009 23:28:34 +0200, gregor herrmann wrote:
>
>> > > > Before sending patch to debhelper, please check if all of these still
>> > > > build. That would help counter the arguemnt that making Build.PL the
>> > > > default may break something.
>> > > And patch packagecheck to check/add "libmodules-perl (>= 5.10) |
>> > > libmodule-build-perl" to Build-Depends in all 2xx affected packages'
>> > > debian/control.
>> > FTR: s/libmodules-perl/perl-modules/ :)
>> Oops, thanks :)
>> And s/TEST_FILES=/--test_files/ in some debian/rules.
>
> And check patches against Makefile.PL that might need conversion to
> patches against Build.PL; including the touch'ing in debian/rules.
>
> 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: U2: God Part II
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoGEzYACgkQOzKYnQDzz+TytwCfWWCG7z09BYyK1vIxM4Sw+ySb
> wJkAnjr0CeoTGhfs7rn/O4KZ+o6NzlAl
> =McsW
> -----END PGP SIGNATURE-----
>
>
Reply to: