> > I dont know the logic behind using Build.pl instead of
> makefile.pl, but the
> > fact that it doesnt create the later by defualt (or so I
> have been told) is
> > in my eyes a serious mistake that will greatly reduce its
> overall uptake in
> > the market. And for those people releasing code without a
> Makefile.pl, I
> > wonder at the point of putting such things on CPAN. (Others
> such as Randal
> > Schwartz have said the same thing)
>
> Module::Build has a compatibility feature that does in fact produce a
> Makefile.PL file for distribution. In addition, you can have both a
> Build.PL and a MakeMaker Makefile.PL if you want to go that route.
Well, I find it odd that it works the way it does. CPAN expects a Makefile.PL. If an author doesnt bother to have makefile.pl created (my understanding is that this is not default, I await correction) then the module is not auto installable by a large cross section of the deployed Perls out there. This is an odd decision about a system intended to replace MakeMaker IMO. Build.PL should disappear and be replaced entirely by Makefile.pl.
But thats an argument I have no expectation of winning.
> > Another serious issue with Module::Build is that for the
> last ages on Win32
> > it doesnt. Have a look at the transaction report of trying
> to install it
> > (using itself) from CPAN. It doesnt play nicely with
> CPAN's prerequisite
> > system, (a Makefile.pl program would have caused CPAN to
> autoload these
> > prerequisites on my system by default) and fails build.
>
> Module::Build has worked on Windows since version 0.16 (it also now
> works on Cygwin as of 0.21); I ported it. Unfortunately the latest
> release (0.21) had some Windows bugs that I didn't catch
> before it was
> released. Despite this last release, I have found it to be
> very stable.
Alas, I have yet to see a stable Win32 build. I do believe that you did one, but.....
> I believe current releases of CPAN(PLUS)? do natively support
> Build.PL files, but I don't use either of them. (I prefer manual installs).
CPANPLUS may do, but i do not think that CPAN does. Even if the latest version does, this doesnt help people who cant upgrade the version that was distributed with their perl, and makes life really difficult for people who "cant install modules".
If you cant install modules then the fact that Module::Build and CPANPLUS exist isnt going to help you much.
The issue here is backwards compatibility. If you want your code to install accross a wide range of OS's and platforms and perl versions then using Module::Build and expecting people to have CPANPLUS is not going to be a winning proposition.
>
> I'm not arguing; I just wanted to clarify a few points. ;)
> Module::Build is a long way from being complete, but I think it's further
> along than you think, and it's catching on relatively fast.
I think it would have caught on a LOT faster if the silly Build.PL decision hadnt been made. Breaking the old stuff is ok once the new stuff has sufficient market penetration. Breaking the old stuff from the get go just means youll never have the market penetration to convince people its worthwhile.
Frankly until Module::Build works seamlessly by default with plain old CPAN I would advance the opinion that it will never replace MakeMaker, and potentially in the long run leave the community divided, with those of us who can using Module::Build and those of us who cant or need to ensure backwards compatibility not. I personally dont think that the balkanization of CPAN is a fair price for the changes that Module::Build brings.
Now if a concerted effort was made to ensure that Module::Build easily installed everywhere (as seen with the prerequisites and Win32 build failure it does not) and that _every_ distribution produced by Module::Build was installable via CPAN.pm then I would feel much more confident about its future.
>
> BTW, If you want to see who and what is using Build.PL, I generated a
> report a while back at http://sourceforge.net/mailarchive/forum.php?thread_id=3333245&forum_id=10905>
Cheers, Ill have a look at it.
Yves
