Windows user

[Bart Lateur]

Because it generally works.

But OTOH, ExtUtils::MakeMaker is pretty much broken.

 

[Ted Zlatanov]

Ted Zlatanov ([email protected]) wrote on MMMDCXXXV September
MCMXCIII in <URL:%% I think most modules (99.99%?) use Makefile.PL, which currently
%% means having to use `make' but, because of what Perl can do
%% internally, could be replaced. Let's assume for the moment that
%% `make' is still useful for compiling modules with C code; I'm
%% talking about pure Perl modules. For those, "perl Makefile.PL;
%% make; make install" could be simply "perl Makefile.PL install" or
%% something similar.

No. Then you are not understanding 'make', which tries to do its
utter best not to create something that is already there.

I doubt that I don't understand `make.' What makes you think that?

%% You and Eric are saying it's no big deal
%% to install `make.' It's not a big deal for experienced users,
%% but at the very least it's a hassle for new Perl users on the
%% Windows platform.

That is not an argument. It would if Perl was the only software that
makes use of 'make', but the fast majority of software requires
'make' to build. The users of a Windows platform would be more
helped with getting 'make', than with Perl circumventing the use of
'make'.

Using software does not have to mean building it. The vast majority
of Windows users, in fact, are quite happy with precompiled
binaries and have never built software. Why not make Perl more
accessible to them? ActiveState Perl already provides PPMs, which
should show you at least that there's a demand for Perl from people
who don't want to bother with building software themselves.

Also, you seem to be equating installing CPAN modules with building
software. In the case of pure-Perl modules, this is usually not true.

But if you think there's a better way: code speaks more than words.

If I think there's no good alternative, I might write my own make.pl,
but 4 such programs have been pointed out already. I might also write
something that interprets Makefile.PL on the fly and skips the `make'
step if possible, but I want to find out if a) such a thing is
planned/exists already, and b) there's a better way to do it.

The simplest fix is to include make.pl (which is compatible with the
standard Makefile syntax, according to its web page) with the CPAN
module and use it instead of `make.' I don't think it's a necessary
step, since all the information needed is already available from the
Makefile.PL, but it can certainly be used for backwards compatibility.

You can't ask that someone write the code every time they point out
inefficiencies or bad design. Sometimes it's the right thing to do,
but sometimes a little research and conversation will save days of
work.

In case it wasn't clear, I started this thread because I was curious
about make alternatives written in Perl (fully answered, thanks), and
why they are not being used to replace `make' in the CPAN install
process. So far, the arguments for the latter have been "because make
works (and is available everywhere)" and "because it's hard to replace
make."

On CPAN, the CPAN.pm modules is going to be replaced by CPANPLUS:

http://search.cpan.org/author/KANE/CPANPLUS-0.042/lib/CPANPLUS/Backend.pm
(look at the install function to see it still uses `make')

So CPANPLUS.pm appears to continue the CPAN.pm `make' usage.

Thanks
Ted

 

[pkent]

....

I missed the start of this thread but this reminds me of:
http://magnonel.guild.net/~schwern/talks/MakeMaker_Is_DOOMED/slides/

P

 

[Ted Zlatanov]

I missed the start of this thread but this reminds me of:
http://magnonel.guild.net/~schwern/talks/MakeMaker_Is_DOOMED/slides/

That was really useful, thanks. It answered pretty much every
question I had.

Ted

 

[Ted Zlatanov]

Anyway, as you yourself thoughtfully pointed out, people wanting to
install (most) CPAN modules can just use ppm or apt-get or rpm or
whatever and install them. This works for pure-Perl as well as XS
modules.

Unfortunately all of those methods are bad in one way or another:

PPM is not easy to use, there's no automatic MakeMaker to PPM
conversion, and virtually none other than ActiveState uses it.

apt-get or RPM know little about the Perl install process, and are not
CPAN-compatible or even OS-independent (modules have to be specially
prepared for a distro, and that's mostly Linux at this point).

I think we've answered those questions so far: a) no. b) we don't
think so, but if you do, you're welcome to prove us wrong. And I'm
quite sincere in that; if you can come up with something that works
in all cases, that's great.


Go to it. Let us know how it goes.

The link posted by pkent to the Module::Build talk by Michael Schwern
convinced me that I really don't need to do this. Module::Build can
generate the wrappers I suggested, down to "make;make install," and it
can rewrite existing MakeMaker configurations. The talk also pretty
much reiterated all my arguments about why we should avoid make - do
read it if you get a chance.

As you seem to be the only person interested in having the code,
you're logically the best person to write it.

Given Schwern's talk, I'm glad you were wrong, rewriting Module::Build
would have been annoying

So submit a patch; if the author like it, no doubt it'll be
accepted.

Module::Build is already supported, so I need do nothing there.

Thanks
Ted

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Ted Zlatanov

That was really useful, thanks. It answered pretty much every
question I had.

While I too consider MakeMaker a broken architecture, this Module::Build
idea is much more broken (not even speaking about the faulty logic in
the presentation cited above).

The beauty of Makefile.PL user interface (as opposed to the - faulty -
packager's interface) is that it was shell-, OS-, filesystem-,
etc-independent. Now comes Build - and the invocation has the ./file
syntax, which is system-dependent!

So now the README for a distribution should contain "If you are on
...., ..., or ..., use the following commands to build this package; if
you are on ..., ..., use these commands; otherwise you are on your
own, since I do not know the shell syntax there". Or if it does not,
it's the users who are delegated the responsibility to find this
out...

This problem might have been trivial to fix when Module::Build was
young - the fault is with trying to mimic MakeMaker's UI ;-) ;-(. But
judging by the reports, now Module::Build may be entrenched enough so
that its UI can't be changed. (Without the packages' READMEs
containing "If the version of Module::Build is less than ..., use the
following commands, otherwise use..." :-().

IMO, one should have abandon `make' and `make test'-like commands at
all, doing the `make; make test' step by default during the `perl
FirstStep.PL' phase. If the finer control is needed, one should be
able to specify this by arguments on the FirstStep.PL line. E.g., one
possible syntax for the standard invocation might have been

perl FirstStep.PL do=config do=build do=test do=install

(with `do=config do=build do=test' being the default if no do= options
are given). [Here FirstStep is just a placeholder, of course...]

Hope this helps,
Ilya

 

[Sam Holden]

[A complimentary Cc of this posting was sent to
Ted Zlatanov

That was really useful, thanks. It answered pretty much every
question I had.

While I too consider MakeMaker a broken architecture, this Module::Build
idea is much more broken (not even speaking about the faulty logic in
the presentation cited above).

The beauty of Makefile.PL user interface (as opposed to the - faulty -
packager's interface) is that it was shell-, OS-, filesystem-,
etc-independent. Now comes Build - and the invocation has the ./file
syntax, which is system-dependent!

Surely it could just say:

perl Build.PL
perl Build test
perl Build install

Instead of:

perl Makefile.PL
make test
make install

One less system depedant thing (making sure make is available and in the
appropriate path). If perl can't be executed, then installing modules is
probably not the most important problem to fix...

[snip the rest]

I agree with most of that

perl Build.PL test
perl Build.PL install

or

perl Build.PL test install

seems better to me - if the initial 'perl Build.PL' step is time intensive then
the module can cache the result after all (maybe in a file called ./Build .

 

[pkent]

[A complimentary Cc of this posting was sent to
Ted Zlatanov
....

The beauty of Makefile.PL user interface (as opposed to the - faulty -
packager's interface) is that it was shell-, OS-, filesystem-,
etc-independent. Now comes Build - and the invocation has the ./file
syntax, which is system-dependent!

I think that was an example of the invocation on a Unix-like system,
just as '/usr/bin/make' is a possible command line in the traditional
perl-module-building process. On my MacPerl system I would not type
anything, because for most users there is nowhere to type... droplets
and double-clicking are alternatives. Saying './Foo' doesn't (afaik)
work on VMS systems, nor any other system (AmigaOS?) where the directory
naming isn't Unix-like.

That's not to say I know much nor endorse Module::Build. I do think that
using make(1) was initially a Good Idea. I do think that this whole idea
of necessarily "using an external make-like tool" is a Bad Idea. Here's
why: when I want to install a module I have, to begin with, a directory
full of files. I want to install them in the Right Place. I _do not_
care how they get there. I'm goal-oriented, not process-oriented. So,
this is what I want to achieve:

check the distro is complete
ask the user some questions (e.g. "What's your http proxy?")
build some documentation from the perl (man pages, html, whatever is
appropriate)
do whatever autosplit-related gubbins needs to be done
alter the shebang line in programs
run 0 or more test programs
install, whatever that means, the docs and the perl modules in the right
place.

None of that -requires- make. But on a Unix system it can be done with
make. The thing is that I don't care -how- it's done, I just want
certain goals achieved. Even if I had XS code I don't -need- make, even
on a unix system. Perl is quite capable of saying:

system('/usr/bin/gcc', '-foo', '-bar'....

And perl is quite capable of copying files around, manifying things,
etc. All by itself without a makefile (or batch script or whatever)
firing off commands.

Now that's not to say that make is bad. It's a fine program and does
some very clever things, and I use it most days. But it's not actually
necessary, when you actually think about the requirements outlined
above. It is very valuable though if you want complex dependencies
worked out. I expect this becomes more apparent with XS modules (not
sure myself - I tend to only compile them on Unix-ish systems)

OTOH the standard 'Makefile.PL' way of doing things does have the
benefit of being a piece of cake and very very standard. Any replacement
should probably be a kind of 'behind the scenes, under the hood' change
than won't affect how people usually work. So to sum up, it's all pretty
tricky

P

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sam Holden

Surely it could just say:

perl Build.PL
perl Build test
perl Build install

Why do you think so? `perl Build' being different from `perl
Build.PL' - this depends on the (undocumented and quite probably
subject to change soon) order of executable extensions for the Perl
scripts. Moreover, who guaranties that there is no F<Build> on the
PATH before '.'?

Ilya

 

[Ken Williams]

Hi Ilya,

Let me preface all my remarks by saying that I'm trying to lead with
the carrot here, not the stick. If Module::Build doesn't offer
significant advantages over MakeMaker, then I would hope nobody will
switch.

The beauty of Makefile.PL user interface (as opposed to the - faulty -
packager's interface) is that it was shell-, OS-, filesystem-,
etc-independent. Now comes Build - and the invocation has the ./file
syntax, which is system-dependent!

Yes, but barely. And I hope people will be able to surmount this
obstacle and figure out how to run a perl script if they're installing
perl modules.

This problem might have been trivial to fix when Module::Build was
young - the fault is with trying to mimic MakeMaker's UI ;-) ;-(. But
judging by the reports, now Module::Build may be entrenched enough so
that its UI can't be changed.

That's probably not true - we can do whatever we want. There can also
be more than one interface to the functionality. There's already the
Build.PL interface, and a programmatic interface we use for
cross-platform testing. If you have a suggestion for how you'd like
to see it work, please open a thread on the Module::Build list,
(e-mail address removed) .

IMO, one should have abandon `make' and `make test'-like commands at
all, doing the `make; make test' step by default during the `perl
FirstStep.PL' phase. If the finer control is needed, one should be
able to specify this by arguments on the FirstStep.PL line.

In order to ease the transition module authors may make from MakeMaker
to M::B, and in order to let people make distributions with both a
Makefile.PL and a Build.PL (which happens quite a lot, and might be
expected to happen basically forever), it is highly desirable that the
config/build/test process is very similar to MakeMaker's. Also, I
considered lots of alternative ways to set things up when M::B was
young, and I decided that many of MakeMaker's metaphors made a lot of
sense, so I didn't change them. This is one of the big ones I kept,
and I think that's been a good decision. It has, for example, enabled
the creation of a pass-through Makefile.PL and Makefile, helping
transitional compatibility with CPAN.pm

-Ken

 

[Ken Williams]

Hi,

I'm not on usenet much, but I just did a google groups search for
Module::Build in order to see whether there were questions about it
out in the world. Feel free to Cc me if you'd like me to stay in the
conversation.

However, there is Module::Build which will sooner or later replace
ExtUtils::MakeMaker. It no longer relies on make but instead produces a
framework that will obey to

perl Build.PL
./Build
./Build test
./Build install

The first line will produce a Perl script 'Build' that contains all the
functionality that was previously specified in Makefile.

Of course, such a change in the build process only makes sense when
other tools can deal with it. For instance, h2xs wont yet create a
module skeleton for Module::Build. I am not sure about CPAN.pm either.
Current release might already be able to deal with those modules, but
older ones certainly aren't.

Those issues aren't too bad. First, it's really quite easy to convert
a project from MakeMaker to Module::Build. I've done it with several
of mine. In many cases people may keep both Makefile.PL and Build.PL
available. See Module::Build::Compat for more information.

Also, for new modules, new versions of h2xs could rather trivially
emit M::B stubs rather than MM stubs. And ExtUtils::ModuleMaker
already does.

Second, for compatibility with old CPAN.pm and such, Module::Build can
provide a Makefile.PL that passes commands through to Module::Build in
a couple of different ways, or it can provide a traditional
Makefile.PL that doesn't require the end user to have Module::Build
around at all. Module::Build::Compat explains this too.

-Ken

 

[Ken Williams]

That's the fourth alternative to make and second make-replacement CPAN
module mentioned so far (Make being the other one). I hope a clear
winner emerges. My opinion is that the existing Makefile.PL has to be
migrated or interpreted seamlessly for CPAN installs, so replacing
ExtUtils::MakeMaker is harder than extending it given the number of
modules and authors.

Nah, it's not too bad. =) It's actually *much* harder to extend
MakeMaker than to replace it - MakeMaker just isn't very extensible.
And writing Module::Build has been easier than expected. A lot of the
hard work has already been done, in modules like File::Spec,
File::Copy, Test::Harness, ExtUtils::Install, etc.

I also should correct a misunderstanding - Module::Build isn't in the
same category as the 'make' replacements. All it does is build &
install perl modules, and there's nothing analogous to 'make' anywhere
in that process when Module::Build is running the show.

There's also the documentation written, volumes and volumes of it in
soft- and hardcopy, that would have to be modified. I'd rather see
the existing Makefile.PL parsed than a new system replacing it.

Unfortunately, MakeMaker's documentation is pretty spotty (in
fairness, it's quite tough to document it, for various reasons), and
the 'make' documentation is mostly irrelevant because the user doesn't
get involved at that level of the process, beyond simple invocations
of targets with occasional variable replacement.

-Ken

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sam Holden

I'm saying that if the module works so that executing Build.PL
creates a perl script called Build in the current directory (which is
implied by the "./Build test" command you mentioned) then after running
perl Build.PL you can just run "perl Build test" instead of "./Build test".

What I was saying was that this is wrong. Why do you think that given
both `Build' and `Build.PL' in the current directory the command `perl
Build' will prefer running `Build' vs. running Build.PL?

On the other hand, it may be that the executable extension logic is
triggered only with -S option; this would make my particular argument
moot - but again, note that this depends on a semi/undocumented feature.

The only thing that matters with respect to the PATH and "perl Build test"
is that "perl" is in the PATH, which is implied by the execution of
"perl Build.PL" or even "perl Makefile.PL".

Without -S switch, my argument was wrong. Thanks for pointing this out.

The command "perl Build test" tells perl to run the script in the file
"Build" in the current working directory and set @ARGV to be ('test').

Is there *any* platform on which this is not true?

You mean "currently" or "in foreseeable future"? I would not vouch in
the second case...

Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Ken Williams

Yes, but barely. And I hope people will be able to surmount this
obstacle and figure out how to run a perl script if they're installing
perl modules.

Why do you think so? E.g., they may be getting LWP just to use
`lwp-download'...

In order to ease the transition module authors may make from MakeMaker
to M::B, and in order to let people make distributions with both a
Makefile.PL and a Build.PL (which happens quite a lot, and might be
expected to happen basically forever), it is highly desirable that the
config/build/test process is very similar to MakeMaker's. Also, I
considered lots of alternative ways to set things up when M::B was
young, and I decided that many of MakeMaker's metaphors made a lot of
sense, so I didn't change them. This is one of the big ones I kept,
and I think that's been a good decision. It has, for example, enabled
the creation of a pass-through Makefile.PL and Makefile, helping
transitional compatibility with CPAN.pm

Do not see how. Can you elaborate?

Yours,
Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Sam Holden

Simply because I can't see any reason why perl would want to do otherwise.

If there are such systems then replace "Build.PL" with "Setup.PL" and
"Build" with "Build.PL" or whatever. The actual names of the files
are pretty much irrelevant to me.

Same for me - as far the files differ by more than extension. But
Module::Build does exactly this.

If there is no platform independant way of specifying run the perl
script "foo" and pass it the argument "bar", then I guess some sort
of english description (better than mine, hopefully) would need to
be used.

It is much easier to fix bugs/problems than document them.

If there are a handful of wierdo architectures that are completely
different then examples of those can be used along with the
general case.

This is not acceptable. I do not want my users to read 20-page README
just to find out how to install things on a non-broken system. Too
many Perl installations are broken; if non-broken ones give troubles
too, the whole idea of supporting modules becomes a nightmare...

If you have no problem with "perl Makefile.PL" as instructions
then I can't see how some name other than "Makefile" can be
a problem.

See above.

Why would that ever change? perl5.8.0 still accepts ' as a package
seperator, why would backwards compatibility be broken so badly for
absolutely no gain whatsoever (as far as I can tell).

Simple: suppose a filesystem does not allow files with empty extensions.

Hope this helps,
Ilya

 

[Sam Holden]

[A complimentary Cc of this posting was sent to
Sam Holden

Simply because I can't see any reason why perl would want to do otherwise.

If there are such systems then replace "Build.PL" with "Setup.PL" and
"Build" with "Build.PL" or whatever. The actual names of the files
are pretty much irrelevant to me.

Same for me - as far the files differ by more than extension. But
Module::Build does exactly this.

The filenames used are a pretty trivial thing to change.

It is much easier to fix bugs/problems than document them.

I don't think there is a bug/problem. As I sais I don't know of a
platform which makes it impossible to run a program and pass it
two command line arguments which are short strings.

This is not acceptable. I do not want my users to read 20-page README
just to find out how to install things on a non-broken system. Too
many Perl installations are broken; if non-broken ones give troubles
too, the whole idea of supporting modules becomes a nightmare...

perl Setup.PL
perl Build.PL test
perl Build.PL install

is hardly 20 pages. If there exists a system where you can't run perl scripts
by name and give them arguments, then that wierdo platform would need
the corresponding three instructions. Maybe create a seperate icon for
each action for system with no command line, or a single icon which prompts
for the arguments in a platform spcific way.

See above.

Makefile.PL is OK, but Setup.PL and Build.PL won't work?

Simple: suppose a filesystem does not allow files with empty extensions.

So use .PL on all the names. As I said the names of the files don't seem
to be a serious issue, that's something which is trivial to change.

But then what about a filesystem which doesn't allow capital letters in names?
Or a filesystem which doesn't allow .s in names? Or a file system which has
a limit of three letters for filenames?

My answer is that you make it work on as many as possible without harsh
restrictions and then specialise for those platforms which are different.

 

[Ted Zlatanov]

[A complimentary Cc of this posting was sent to Sam Holden
<[email protected]>:

perl Setup.PL
perl Build.PL test
perl Build.PL install

is hardly 20 pages.

Would this be the case, great. However, I still have no idea why
the second line is needed... IMO, the default should be to do
config/build/test cycle; and it is better to keep install a
different command.

I don't think running tests should be a part of the config/build
process. It's not now.

Ted

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Ted Zlatanov

I don't think running tests should be a part of the config/build
process. It's not now.

I'm not discussing any "process". What I'm discussing is the
*default* action. E.g., the above sequence can be modelled by

perl Setup.PL do=config do=build
perl Setup.PL do=test
perl Setup.PL do=install

or by

perl Setup.PL do=config do=build do=test do=install

My suggestion is that it should be equivalent to

perl Setup.PL
perl Setup.PL do=install

or

perl Setup.PL do=all

(with syntax subject to change).

Hope this helps,
Ilya

 

[Philip Newton]

Windows users have ActiveState
and that other distribution whose name I can never remember with
Apache + Perl.

IndigoPerl: http://www.indigostar.com/indigoperl.htm

Cheers,
Philip