module-build-general — General discussion about Module::Build project

Re: [Module-build-general] A better passthrough Makefile.PL

[Ken W. <ke...@ma...>]

On Friday, November 1, 2002, at 01:12  AM, Dave Rolsky wrote:

> On Thu, 31 Oct 2002, Ken Williams wrote:
>> This is kind of tough to test out - Dave, how did you test this before?
>
> I tested this by uploading a module to CPAN with this Makefile.PL
> (Thesaurus 0.21) and installing it.  Very elegant ;)

Heh - that's sort of a "plan Z" scenario.

> FWIW, it did work quite well.  I think your change above may work just 
> as
> well.  If anyone knows of a way to force CPAN to install something 
> from a
> tarball (as opposed to fetching the tarball from elsewhere), that'd be
> very helpful in testing this sort of stuff.

I'll see if I can figure that out.

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

[Dave R. <au...@ur...>]

On Thu, 31 Oct 2002, Ken Williams wrote:

> I think this is a decent change.  Autrijus, I think it's better to use
> ExtUtils::MakeMaker here than ExtUtils::AutoInstall, simply because the
> user will have the former but probably not the latter.
>
> Actually, I just had an idea - would the following small change work
> (note the 'touch' line, "open $0")?
>
>    unless (eval "use Module::Build::Compat 0.02; 1" ) {
>      # Workaround with old CPAN.pm and CPANPLUS.pm
>      require ExtUtils::MakeMaker;
>      ExtUtils::MakeMaker::WriteMakefile(
>        PREREQ_PM => { 'Module::Build::Compat' => 0.02 }
>      );
>      warn "Warning: prerequisite Module::Build::Compat is not found.\n";
>      sleep 2;  # Wait a couple seconds after writing Makefile
>      open my($fh), ">> $0"  # Change modification date
>        or warn "You may have to run 'perl Makefile.PL' again.";
>      exit(0);
>    }
>    Module::Build::Compat->run_build_pl(args => \@ARGV);
>    Module::Build::Compat->write_makefile();
>
> The idea is that it changes the modification time for Makefile.PL to be
> after the Makefile's, so that Makefile.PL gets re-run.  This is kind of
> tough to test out - Dave, how did you test this before?

I tested this by uploading a module to CPAN with this Makefile.PL
(Thesaurus 0.21) and installing it.  Very elegant ;)

FWIW, it did work quite well.  I think your change above may work just as
well.  If anyone knows of a way to force CPAN to install something from a
tarball (as opposed to fetching the tarball from elsewhere), that'd be
very helpful in testing this sort of stuff.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] A better passthrough Makefile.PL

[Ken W. <ke...@ma...>]

On Friday, November 1, 2002, at 12:29  AM, David Wheeler wrote:

> On Thursday, October 31, 2002, at 07:17  PM, Ken Williams wrote:
>
>> This is probably pretty important for generic application 
>> installation.  It's also a good way to make installation more 
>> intuitive (here's *why* the build failed).
>>
>> Unfortunately I don't have a great answer to this problem.  Autrijus, 
>> weren't you working on something like this a while back, or am I 
>> remembering wrong?
>
> Actually, I think that was me. I developed App::Info to manage non-Perl 
> dependencies, and I think that it could work very nicely with M::B. 
> Unfortunately, I don't have much time to work on it at the moment, but 
> it's definitely on my To Do list.
>
> App::Info is on the CPAN, for those of you who are interested.

Ah yes!  Thanks for piping up, that's what I was thinking of.  I'm 
installing now to check it out.

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

[David W. <da...@wh...>]

On Thursday, October 31, 2002, at 07:17  PM, Ken Williams wrote:

> This is probably pretty important for generic application 
> installation.  It's also a good way to make installation more 
> intuitive (here's *why* the build failed).
>
> Unfortunately I don't have a great answer to this problem.  Autrijus, 
> weren't you working on something like this a while back, or am I 
> remembering wrong?

Actually, I think that was me. I developed App::Info to manage non-Perl 
dependencies, and I think that it could work very nicely with M::B. 
Unfortunately, I don't have much time to work on it at the moment, but 
it's definitely on my To Do list.

App::Info is on the CPAN, for those of you who are interested.

Regards,

David

-- 
David Wheeler                                     AIM: dwTheory
da...@wh...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Th...@ja...

Re: [Module-build-general] A better passthrough Makefile.PL

[Ken W. <ke...@ma...>]

On Saturday, October 12, 2002, at 01:23  PM, Dave Rolsky wrote:

> On Sun, 13 Oct 2002, Autrijus Tang wrote:
>
>>>   unless (eval { require Module::Build::Compat; 1 }) {
>>
>> This may very well pass whilst the M::B requirement (0.11) exceeds
>> the user's own version (0.10), a situation that occured to me today.
>>
>> Maybe should test for the minimal M::B version here?
>
> Yep, good thinking.  That should probably test for 0.11 at least.
> Something like:
>
>   unless (eval { require Module::Build::Compat; 
> Module::Build->VERSION(0.11) ? 1 : 0 })
>
> or something like that.

I think what I'll do is bump the M::B::Compat version to 0.02, and 
document it as:

   unless (eval "use Module::Build::Compat 0.02; 1" ) {

I was trying to avoid eval-expr, but c'est la vie.


>
>>>       my $yn = ExtUtils::MakeMaker::prompt( '  Install 
>>> Module::Build', 'y' );
>>>       if ($yn =~ /^y(es)?/i) {
>>> 	  # save this cause CPAN will chdir all over the place.
>>> 	  my $cwd = cwd();
>>> 	  my $makefile = File::Spec->rel2abs($0);
>>> 	  require CPAN;
>>> 	  CPAN->install('Module::Build');
>>
>> This is largely a skeletal rework of ExtUtils::AutoInstall
>> functionalities.  Are you interested with the idea that I work
>> a M::B compatibility layer into EU::AI, and for the bootstrap
>> code to include the EU::AI bootstrap code that, in addition
>> to fetch M::B automatically, also installs the prereqs
>> at 'Build' time?
>
> Actually, what I was thinking of was putting chunks (all?) of EU::AI 
> into
> Module::Build somehow.  Given that M::B will (I really hope) end up in 
> the
> core for 5.10, I think this makes the most sense.  My goal re: M::B is 
> to
> help it become a much easier to use, more featureful replacement for
> EU::MakeMaker.

I've been ruminating on this, and I think what I want to do is put hooks 
into M::B that will use EU::AI if it's installed (and if the user wants 
auto-installation), but that EU::AI should remain the way to 
automatically install modules.  M::B should use EU::AI, not Borg its 
code.  Obviously this is better from a separation-of-labor & modularity 
point of view, and I think it feels better from a policy point of view 
too.

EU::AI can be a recommended dependency for M::B then.


> In addition, I think it works really well as a generic _application_
> installer.  For example, the example web site for the MasonBook is
> distributed with a Build.PL that besides just installing a couple 
> modules,
> also does the following:
>
> 1. Asks the user where to install the Mason components.
> 2. Asks about how to connect to the RDBMS to be used for the site.
> 3. When 'Build install' is run, it installs the Mason components _and_
> sets up the database (with Alzabo's help), including inserting some
> default data (like categories and an admin user).

Yeah, it's nice if M::B can be used for stuff like this.

One of the main things that needs to be figured out for M::B is how to 
determine other kinds of dependencies that aren't Perl module 
dependencies.  This is probably pretty important for generic application 
installation.  It's also a good way to make installation more intuitive 
(here's *why* the build failed).

Unfortunately I don't have a great answer to this problem.  Autrijus, 
weren't you working on something like this a while back, or am I 
remembering wrong?

A very related problem is the idea of alternative dependencies - for 
instance, Crypt::SKey needs either Digest::MD4 or Digest::MD5, but 
there's no great way to indicate that with M::B's dependency 
specification right now.

  -Ken

Re: [Module-build-general] A better passthrough Makefile.PL

[Ken W. <ke...@ma...>]

On Thursday, October 3, 2002, at 06:54  PM, Dave Rolsky wrote:
> I wanted to create a Makefile.PL that would pass all functionality 
> through
> to Module::Build, _and_ that would make sure that Module::Build got
> installed if necessary.  I also wanted to make sure that the user did 
> not
> have to run "perl Makefile.PL" twice, once for installing Module::Build,
> and once to install the desired module.  Having to do this basically 
> makes
> the install fail with CPAN or CPANPLUS.
>
> Here's what I came up with:
>
>
>   use Cwd;
>   use File::Spec;
>
>   unless (eval { require Module::Build::Compat; 1 }) {
>       require ExtUtils::MakeMaker;
>
>       print "This module required Module::Build to install itself.\n";
>
>       my $yn = ExtUtils::MakeMaker::prompt( '  Install Module::Build', 
> 'y' );
>
>       if ($yn =~ /^y(es)?/i) {
> 	  # save this cause CPAN will chdir all over the place.
> 	  my $cwd = cwd();
> 	  my $makefile = File::Spec->rel2abs($0);
>
> 	  require CPAN;
> 	  CPAN->install('Module::Build');
>
> 	  chdir $cwd
> 	      or die "Cannot chdir to $cwd: $!";
>
> 	  exec( $^X, $makefile, @ARGV )
>       } else {
> 	  warn "Cannot install Thesaurus without Module::Build.  Exiting 
> ...\n";
> 	  exit 0;
>       }
>   }
>
>   require Module::Build::Compat;
>   Module::Build::Compat->run_build_pl( args => \@args );
>   Module::Build::Compat->write_makefile;

I think this is a decent change.  Autrijus, I think it's better to use 
ExtUtils::MakeMaker here than ExtUtils::AutoInstall, simply because the 
user will have the former but probably not the latter.

Actually, I just had an idea - would the following small change work 
(note the 'touch' line, "open $0")?

   unless (eval "use Module::Build::Compat 0.02; 1" ) {
     # Workaround with old CPAN.pm and CPANPLUS.pm
     require ExtUtils::MakeMaker;
     ExtUtils::MakeMaker::WriteMakefile(
       PREREQ_PM => { 'Module::Build::Compat' => 0.02 }
     );
     warn "Warning: prerequisite Module::Build::Compat is not found.\n";
     sleep 2;  # Wait a couple seconds after writing Makefile
     open my($fh), ">> $0"  # Change modification date
       or warn "You may have to run 'perl Makefile.PL' again.";
     exit(0);
   }
   Module::Build::Compat->run_build_pl(args => \@ARGV);
   Module::Build::Compat->write_makefile();

The idea is that it changes the modification time for Makefile.PL to be 
after the Makefile's, so that Makefile.PL gets re-run.  This is kind of 
tough to test out - Dave, how did you test this before?

  -Ken

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Ken W. <ke...@ma...>]

On Monday, October 28, 2002, at 08:20  PM, Dave Rolsky wrote:
> Now is someone (cough, Ken) would get back to working on Module::Build
> then _I_ could get back to working on it.  Right now I've mostly stopped
> looking at it cause my patches are not being integrated.  There's more 
> I'd
> like to be able to add/fix but it's difficult to do if there's old 
> patches
> still not applied/rejected.

Yeah.  I'm working more on it now.  Probably shouldn't be, but I am.

  -Ken

Re: [Module-build-general] make install busted on OS X

[Ken W. <ke...@ma...>]

On Sunday, October 27, 2002, at 02:46  PM, Brian Ingerson wrote:
> OS X has a file system that is case insensitive. Due to the fact that
> you have a file called INSTALL, you should really add the following line
> to your Makefile:
>
>     .PHONY: install
>
> Otherwise the file dependency is always satisfied and 'make install'
> does nothing.

Thanks, I'll apply as soon as I'm back on the net (in a coffee shop at 
the moment).

  -Ken

Re: [Module-build-general] verbose and Test::Harness

[Ken W. <ke...@ma...>]

I've applied this, with a test.  Can you try 'Build test' now?  For 
kicks, also 'Build test verbose=1'.

  -Ken

On Friday, August 23, 2002, at 12:10  PM, Dave Rolsky wrote:

> There's a number of different versions of Test::Harness out there, and 
> at
> least with the one installed on my system (2.24), "Build test verbose=1"
> does not actually lead to verbose output.  This patch fixes that while
> still preserving the old code, which presumably works with some versions
> of Test::Harness.
>
> This also does the same thing for test 'switches', on the theory that it
> can't hurt.  I'm not really sure how to test this.
>
>
> -dave
>
>
> diff -wru ../Module-Build-0.11/lib/Module/Build/Base.pm 
> ./lib/Module/Build/Base.pm
> --- ../Module-Build-0.11/lib/Module/Build/Base.pm	2002-08-24 
> 00:58:27.000000000 +0800
> +++ ./lib/Module/Build/Base.pm	2002-08-24 01:08:10.000000000 +0800
> @@ -563,9 +563,16 @@
>
>    $self->depends_on('build');
>
> -  local $Test::Harness::switches = '-w -d' if 
> $self->{properties}{debugger};
> -  local $Test::Harness::verbose = $self->{properties}{verbose} || 0;
> -  local $ENV{TEST_VERBOSE} = $self->{properties}{verbose} || 0;
> +  local ($Test::Harness::switches,
> +         $Test::Harness::Switches,
> +         $ENV{HARNESS_PERL_SWITCHES}) = ('-w -d') x 2
> +             if $self->{properties}{debugger};
> +
> +  my $verbose = $self->{properties}{verbose} || 0;
> +
> +  local ($Test::Harness::verbose,
> +         $Test::Harness::Verbose,
> +         $ENV{TEST_VERBOSE},
> +         $ENV{HARNESS_VERBOSE}) = ($verbose) x 4;
>
>    # Make sure we test the module in blib/
>    {

Re: [Module-build-general] verbose and Test::Harness

[Ken W. <ke...@ma...>]

On Tuesday, October 29, 2002, at 05:36  PM, Dave Rolsky wrote:

> On Tue, 29 Oct 2002, Ken Williams wrote:
>>
>> So, your version of Test::Harness uses $Verbose instead of $verbose?
>> I'm looking at T::H version 1.1604, which exports $verbose.
>
> It claims to _also_ export $verbose (which is aliased to $Verbose), but 
> in
> practice I found I needed to set the capitalized version.

OK

>> Where are the HARNESS_VERBOSE and HARNESS_PERL_SWITCHES variables used?
>> I can't find 'em in my @INC.
>
> In @INC?  Huh, why would you expect to find them there?

I meant those strings aren't anywhere in the contents of any of the 
files in my @INC directories.

> You should grab a copy of Test::Harness off CPAN and browse through it a
> bit.  It mentions those ENV vars.

OK.

  -Ken

Re: [Module-build-general] verbose and Test::Harness

[Dave R. <au...@ur...>]

On Tue, 29 Oct 2002, Ken Williams wrote:

> I'm about to apply a form of this patch.  I want to make sure I
> understand it.

I wish I remembered more about writing it ;)

> Yeah, "Build test verbose=1" produces verbose output for me.  Someone
> else told me that it didn't for them, though, so I know you're not alone.

You have the pre-Schwern Test::Harness ;)

> > diff -wru ../Module-Build-0.11/lib/Module/Build/Base.pm
> > ./lib/Module/Build/Base.pm
> > --- ../Module-Build-0.11/lib/Module/Build/Base.pm	2002-08-24
> > 00:58:27.000000000 +0800
> > +++ ./lib/Module/Build/Base.pm	2002-08-24 01:08:10.000000000 +0800
> > @@ -563,9 +563,16 @@
> >
> >    $self->depends_on('build');
> >
> > -  local $Test::Harness::switches = '-w -d' if
> > $self->{properties}{debugger};
> > -  local $Test::Harness::verbose = $self->{properties}{verbose} || 0;
> > -  local $ENV{TEST_VERBOSE} = $self->{properties}{verbose} || 0;
> > +  local ($Test::Harness::switches,
> > +         $Test::Harness::Switches,
> > +         $ENV{HARNESS_PERL_SWITCHES}) = ('-w -d') x 2
> > +             if $self->{properties}{debugger};
>
> Should be 'x 3', right?

Yes.

> > +
> > +  my $verbose = $self->{properties}{verbose} || 0;
> > +
> > +  local ($Test::Harness::verbose,
> > +         $Test::Harness::Verbose,
> > +         $ENV{TEST_VERBOSE},
> > +         $ENV{HARNESS_VERBOSE}) = ($verbose) x 4;
>
> So, your version of Test::Harness uses $Verbose instead of $verbose?
> I'm looking at T::H version 1.1604, which exports $verbose.

It claims to _also_ export $verbose (which is aliased to $Verbose), but in
practice I found I needed to set the capitalized version.

> Where are the HARNESS_VERBOSE and HARNESS_PERL_SWITCHES variables used?
> I can't find 'em in my @INC.

In @INC?  Huh, why would you expect to find them there?

You should grab a copy of Test::Harness off CPAN and browse through it a
bit.  It mentions those ENV vars.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] verbose and Test::Harness

[Ken W. <ke...@ma...>]

Heya,

I'm about to apply a form of this patch.  I want to make sure I 
understand it.


On Friday, August 23, 2002, at 12:10  PM, Dave Rolsky wrote:
> There's a number of different versions of Test::Harness out there, and 
> at
> least with the one installed on my system (2.24), "Build test verbose=1"
> does not actually lead to verbose output.  This patch fixes that while
> still preserving the old code, which presumably works with some versions
> of Test::Harness.

Yeah, "Build test verbose=1" produces verbose output for me.  Someone 
else told me that it didn't for them, though, so I know you're not alone.


>
> This also does the same thing for test 'switches', on the theory that it
> can't hurt.  I'm not really sure how to test this.

One sort of ugly way would be to invoke a 'Build test verbose=1' process 
and see whether it really is verbose.  Or we could isolate the code that 
generates the Test::Harness verbosity options, and test that it works by 
sending those options directly to a Test::Harness process.  That would 
be better.  Maybe it wouldn't even require a subprocess?


> diff -wru ../Module-Build-0.11/lib/Module/Build/Base.pm 
> ./lib/Module/Build/Base.pm
> --- ../Module-Build-0.11/lib/Module/Build/Base.pm	2002-08-24 
> 00:58:27.000000000 +0800
> +++ ./lib/Module/Build/Base.pm	2002-08-24 01:08:10.000000000 +0800
> @@ -563,9 +563,16 @@
>
>    $self->depends_on('build');
>
> -  local $Test::Harness::switches = '-w -d' if 
> $self->{properties}{debugger};
> -  local $Test::Harness::verbose = $self->{properties}{verbose} || 0;
> -  local $ENV{TEST_VERBOSE} = $self->{properties}{verbose} || 0;
> +  local ($Test::Harness::switches,
> +         $Test::Harness::Switches,
> +         $ENV{HARNESS_PERL_SWITCHES}) = ('-w -d') x 2
> +             if $self->{properties}{debugger};

Should be 'x 3', right?


> +
> +  my $verbose = $self->{properties}{verbose} || 0;
> +
> +  local ($Test::Harness::verbose,
> +         $Test::Harness::Verbose,
> +         $ENV{TEST_VERBOSE},
> +         $ENV{HARNESS_VERBOSE}) = ($verbose) x 4;

So, your version of Test::Harness uses $Verbose instead of $verbose?  
I'm looking at T::H version 1.1604, which exports $verbose.

Where are the HARNESS_VERBOSE and HARNESS_PERL_SWITCHES variables used?  
I can't find 'em in my @INC.

  -Ken

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Brian I. <in...@tt...>]

On 28/10/02 16:56 -0600, Ken Williams wrote:

Ken, 

Thanks for looking over CPAN::MakeMaker and commenting. I know that the
CPAN::MakeMaker way of thinking is counterintuitive to the traditional
Perl way of thinking. (Especially to somebody in the midst of writing a
new traditional Perl build system.) But I really think it makes the most
sense as I will attempt to explain. Stay with me here...

> On Sunday, October 27, 2002, at 11:20  PM, Dave Rolsky wrote:
> > On Sun, 27 Oct 2002, Brian Ingerson wrote:
> >
> >> FYI. (NOTE: Even though this seems like a competitive module, I
> >> really think that Module::Build and CPAN::MakeMaker are somewhat
> >> orthoganal. I'm looking forward to working together. There is a good
> >> chance that these modules could nicely complement each other. Let the
> >> thinking begin :)
> >
> > I like that self-instaling feature.  I wonder if we could/should
> > incorporate that for Module::Build.
> 
> I'm generally against "auto-installing" things.  I was going to ask what 
> mechanism CPAN::MakeMaker actually uses to "just work", since I can 
> think of at least three:

CP::MM doesn't auto-install anything at all on the USER system. On the
AUTHOR system, it simply adds a file called ./CPAN/MakeMaker to your
working directory and updates your MANIFEST. It does this because the
AUTHOR asked it to, (implicitly) by using CPAN::MakeMaker in their
Makefile.PL. (I could make it explicit but I feel that would be error
prone in the long run.)

A USER will never have CP::MM on their system at all. (Unless they are
also an AUTHOR. :)

>   1) viral: it auto-installs itself on the host system

Not viral. Doesn't install on USER system.

>   2) catalyst: it doesn't need to be installed, it just needs to be 
> present when installing.

Right. That's the ticket!

>   3) stealth: it isn't even present in the tarballs that use it, it just 
> inserts/changes a bunch of code in the tarballs so they can do what they 
> need to do

Yucky :)

> I'm against doing #1 for M::B.  #2 is fine in principal, as long as 
> newer versions on the system would still be honored.  #3 is kind of 
> yucky.

Good.

> > Maybe we could offer a 'Build uberdist' feature or something that would
> > simply incorporate all of the M::B files into the tarball.  As long as
> > they end up untarring into the top-level of the distro (./Module,
> > ./Module/Base.pm, etc) it'd just work.
> >
> > This could even be the default for Module::Build.
> 
> I'm not crazy about the idea that using M::B would bloat your 
> distribution with its own by default.  In my mind this is better solved 
> by getting dependency relationships that express the situation 
> correctly, then letting the user (or automated system) resolve those 
> dependencies.  That leaves you with a better dependency map too.

My hope is that CP:MM will get to where it can build a custom version of
itself that only includes code for the features that the AUTHOR has
used. So any bloat, would only be *necessary* bloat. And if you think
about it, the AUTHOR is no longer going to need to write a lot of code
to do the stuff that the "bloat" is now doing. So it may end up that
overall, there is no difference in distribution size.

You are right about getting the dependency mapping right. I hope to offer
some good options here and hopefully ones that are compatible with M::B. 

On 28/10/02 17:14 -0600, Ken Williams wrote:
>
> On Sunday, October 27, 2002, at 07:48  PM, Brian Ingerson wrote:
> > CPAN/MakeMaker version 0.10
> > ===========================
> >
> > The module ExtUtils::MakeMaker is familiar to everybody. It's on the
> > first line of every Makefile.PL of every module distribution on CPAN.
>
> Well, most of them.
>
> Anyway, I do think this is a bit of a step backwards.  I don't really
> like the idea of including CPAN::MakeMaker in every module distributed,
> but that's largely an aesthetic argument against making zillions of
> distributions with the same installation code, and having to deal with
> the associated problems with it.

If I get to the point where CP::MM is custom, then there won't be
hundreds (there aren't a zillion distros yet :) of copies of the same
code. It will be exactly the code that is right for each distro. And
less custom code rewritten by each AUTHOR.

And remember, in XP terms, duplication is OK as long as there is only
one canonical copy, and other copies are derivative. This is actually a
large scale refactoring and code reduction for CPAN. That's SOOO cool!

> Also, one of the main reasons I aborted my project to "fix" EU::MM was
> that I became convinced that its OO architecture is bad (upside-down,
> mostly) and unfixable.  I'm concerned that CPAN::MM will be like trying
> to patch a turd.

My plan is to build a wrapper OO architecture that is right side up and
fixable. It doesn't matter so much what the underlying turds are. 

I must also say that I rather like EU::MM for the fact that it does so much
(even if it does it in an arcane manner). The beauty of EU::MM is that there
is a common code base to leverage on every installation of Perl 5. You just
can't ignore that.

> I don't mean to discourage you from working on it, but these are my
> reservations about its success.

In the final analysis, nobody has to use CP::MM or M::B. If they are
useful they probably will get used, and if they aren't they probably
won't. That's just Perl.

> > The good thing about ExtUtils::MakeMaker is that it is powerful,
> > featureful, flexible, cross-platform and on virtually every installation
> > of Perl 5.
>
> That's also true of the other ExtUtils::* modules, which I happily use
> in Module::Build.
>
> > The bad thing about this legacy workhorse is that the Perl
>
> > The bad thing about this legacy workhorse is that the Perl
> > community is crippled to significantly improve it. Any features added
> > now can only enhance the current release of Perl. Authors would shun new
> > features anyway, because their modules could not be used in earlier
> > versions of Perl that account for the overwhelming majority of
> > installations.
>
> So why not just add new features to ExtUtils::MakeMaker and put that
> in ./ of each module that wants to use the new features?

Too big. I can be stealth. 

Also, since EU::MM is already on every system the old one would get
executed, because '.' is at the end of @INC. EU::MM doesn't know to load
the local one like CP::MM does.

> > CPAN::MakeMaker is a self-distributing module.
>
> After reading your documentation and seeing that it's not viral, I'd
> change the above phrase.  I assumed it was viral when I read this.

Good point.


On 28/10/02 17:22 -0600, Ken Williams wrote:
>
> On Monday, October 28, 2002, at 12:42  AM, Brian Ingerson wrote:
> > You have to make sure that an *installed* copy of M::B reloads the local
> > copy. The installed version will always be found first. But ultimately,
> > it's the local copy you want to execute, because that is the one that
> > the module author configured his distribution for. This is *essential*.
> > If you do it, you'll never have versioning problems. If you don't you'll
> > be plagued by them.
>
> Suppose there's a security bug in M::B, though - if I adopt the above
> policy, a user couldn't just update M::B on their system to fix the
> bug.  They'd also have to make sure all software they installed later
> that uses M::B also had a fixed version.  That

That's the problem that I see with M::B. You have to get it everywhere,
and upgrade it everywhere. Making it yet another dependency is going to
get irksome, IMO. As an AUTHOR, I'm not willing to risk the excess
dependency stigma for my modules if I can avoid it. Especially for my
less known modules.

If there is a security problem, then with M::B you have a zillion copies
of the problem out there (there actually *are* a zillion installations
of Perl ;).

With CP::MM you don't have any insecure code on the USER systems. You
have a handful of copies of the problem inside some AUTHOR's distros.
And only the ones who have packaged with a bad copy of CP::MM. They
simply redistribute their distros with the fixed CP::MM and the *entire*
security problem is eliminated. No messy residue!

And all the AUTHORs will find out about the bug much sooner than all the
USERs would. Because the first USER to get bit by the bug is going to
bite the AUTHOR in a heartbeat!

> > One problem the current M::B faces is that it not only needs to get a
> > copy of M::B on every install (an extremely formidable task in its own
> > right)
>
> It's not too hard.  The current pass-through Makefile.PL lists M::B as a
> dependency, so CPAN.pm (and similar) will install it.

Am I the only one who still installs their modules by hand? I hate
dependencies, but not as much as shell utilities that are awkward to set
up, sometimes flaky, and worst of all need to be run as root.

FWIW, on Unix w/ sudo, I can do an entire installation of a module (with
no dependencies) safely, using a simple bash function. With dependencies
I'd probably have to write it in Perl and pretty soon we'd have yet
another CPAN shell :P

> > it also needs to have a compatible version of itself everywhere.
> > How do you advance?
>
> By having authors list the required version of M::B as a build
> dependency.
>
>
> > If you do the self install route, you have one other issue to tackle.
> > What happens to all the existing M::B installs? They don't know how to
> > play the game. They must be removed, or you must change your module
> > What happens to all the existing M::B installs? They don't know how to
> > play the game. They must be removed, or you must change your module
> > name. I ran into this problem with Inline::MakeMaker, the precedent to
> > C::MM. I was going to need to find a way to nuke the old ones. Now I'm
> > saved by the fact that I can move all the planned Inline logic into
> > C::MM which doesn't (and won't) have legacy problems.
>
> Hmm, seems like the same thing can just happen with CPAN::MM later,
> though.

I'd certainly like to know how. Since it never installs on the USER
side, there is *no legacy* by definition. I could put out a completely
different UI/API every day until the end of time, and never break
anything. I wouldn't do that, but theoretically I could.

Only the AUTHOR needs to know about the current CP::MM feature set,
which is always in the current POD documentation.

> > See Ken? We shoulda spent more time talking and less time having fun at
> > OSCon
> > ;)
>
> I tend not to plan things very well in person, though, which generally
> makes me useless face-to-face. ;-)

But we sure did have fun! :D

Cheers, Brian

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Dave R. <au...@ur...>]

On Mon, 28 Oct 2002, Ken Williams wrote:

> > One problem the current M::B faces is that it not only needs to get a
> > copy of M::B on every install (an extremely formidable task in its own
> > right)
>
> It's not too hard.  The current pass-through Makefile.PL lists M::B as a
> dependency, so CPAN.pm (and similar) will install it.

The problem is that CPAN won't follow through and finish the install of
the module you were trying to install in the first place.

However, I think the proposed Makefile.PL I sent earlier (plus tweaks from
Autrijus) does solve this problem.

Basically, what I want to see is for CPAN or CPANPLUS to be able to
install a Module::Build-using module in _one_ step.

This works right now for CPAN with the Makefile.PL I created.  Adding
support for CPANPLUS to that would probably be trivial.

So I guess I no longer am all excited about the self-install option ;)

Now is someone (cough, Ken) would get back to working on Module::Build
then _I_ could get back to working on it.  Right now I've mostly stopped
looking at it cause my patches are not being integrated.  There's more I'd
like to be able to add/fix but it's difficult to do if there's old patches
still not applied/rejected.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Ken W. <ke...@ma...>]

On Monday, October 28, 2002, at 12:42  AM, Brian Ingerson wrote:
> You have to make sure that an *installed* copy of M::B reloads the local
> copy. The installed version will always be found first. But ultimately,
> it's the local copy you want to execute, because that is the one that
> the module author configured his distribution for. This is *essential*.
> If you do it, you'll never have versioning problems. If you don't you'll
> be plagued by them.

Suppose there's a security bug in M::B, though - if I adopt the above 
policy, a user couldn't just update M::B on their system to fix the 
bug.  They'd also have to make sure all software they installed later 
that uses M::B also had a fixed version.  That

> One problem the current M::B faces is that it not only needs to get a
> copy of M::B on every install (an extremely formidable task in its own
> right)

It's not too hard.  The current pass-through Makefile.PL lists M::B as a 
dependency, so CPAN.pm (and similar) will install it.


> it also needs to have a compatible version of itself everywhere.
> How do you advance?

By having authors list the required version of M::B as a build 
dependency.


> If you do the self install route, you have one other issue to tackle.
> What happens to all the existing M::B installs? They don't know how to
> play the game. They must be removed, or you must change your module
> name. I ran into this problem with Inline::MakeMaker, the precedent to
> C::MM. I was going to need to find a way to nuke the old ones. Now I'm
> saved by the fact that I can move all the planned Inline logic into
> C::MM which doesn't (and won't) have legacy problems.

Hmm, seems like the same thing can just happen with CPAN::MM later, 
though.

> See Ken? We shoulda spent more time talking and less time having fun at 
> OSCon
> ;)
>

I tend not to plan things very well in person, though, which generally 
makes me useless face-to-face. ;-)

  -Ken

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Ken W. <ke...@ma...>]

On Sunday, October 27, 2002, at 07:48  PM, Brian Ingerson wrote:
> CPAN/MakeMaker version 0.10
> ===========================
>
> The module ExtUtils::MakeMaker is familiar to everybody. It's on the
> first line of every Makefile.PL of every module distribution on CPAN.

Well, most of them.

Anyway, I do think this is a bit of a step backwards.  I don't really 
like the idea of including CPAN::MakeMaker in every module distributed, 
but that's largely an aesthetic argument against making zillions of 
distributions with the same installation code, and having to deal with 
the associated problems with it.

Also, one of the main reasons I aborted my project to "fix" EU::MM was 
that I became convinced that its OO architecture is bad (upside-down, 
mostly) and unfixable.  I'm concerned that CPAN::MM will be like trying 
to patch a turd.

I don't mean to discourage you from working on it, but these are my 
reservations about its success.


> The good thing about ExtUtils::MakeMaker is that it is powerful,
> featureful, flexible, cross-platform and on virtually every installation
> of Perl 5.

That's also true of the other ExtUtils::* modules, which I happily use 
in Module::Build.

> The bad thing about this legacy workhorse is that the Perl
> community is crippled to significantly improve it. Any features added
> now can only enhance the current release of Perl. Authors would shun new
> features anyway, because their modules could not be used in earlier
> versions of Perl that account for the overwhelming majority of
> installations.

So why not just add new features to ExtUtils::MakeMaker and put that 
in ./ of each module that wants to use the new features?


> CPAN::MakeMaker is a self-distributing module.

After reading your documentation and seeing that it's not viral, I'd 
change the above phrase.  I assumed it was viral when I read this.

  -Ken

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Ken W. <ke...@ma...>]

On Sunday, October 27, 2002, at 11:20  PM, Dave Rolsky wrote:

> On Sun, 27 Oct 2002, Brian Ingerson wrote:
>
>> FYI. (NOTE: Even though this seems like a competitive module, I
>> really think that Module::Build and CPAN::MakeMaker are somewhat
>> orthoganal. I'm looking forward to working together. There is a good
>> chance that these modules could nicely complement each other. Let the
>> thinking begin :)
>
> I like that self-instaling feature.  I wonder if we could/should
> incorporate that for Module::Build.

I'm generally against "auto-installing" things.  I was going to ask what 
mechanism CPAN::MakeMaker actually uses to "just work", since I can 
think of at least three:

  1) viral: it auto-installs itself on the host system

  2) catalyst: it doesn't need to be installed, it just needs to be 
present when installing.

  3) stealth: it isn't even present in the tarballs that use it, it just 
inserts/changes a bunch of code in the tarballs so they can do what they 
need to do

I'm against doing #1 for M::B.  #2 is fine in principal, as long as 
newer versions on the system would still be honored.  #3 is kind of 
yucky.

> Maybe we could offer a 'Build uberdist' feature or something that would
> simply incorporate all of the M::B files into the tarball.  As long as
> they end up untarring into the top-level of the distro (./Module,
> ./Module/Base.pm, etc) it'd just work.
>
> This could even be the default for Module::Build.

I'm not crazy about the idea that using M::B would bloat your 
distribution with its own by default.  In my mind this is better solved 
by getting dependency relationships that express the situation 
correctly, then letting the user (or automated system) resolve those 
dependencies.  That leaves you with a better dependency map too.

  -Ken

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Brian I. <in...@tt...>]

On 27/10/02 23:20 -0600, Dave Rolsky wrote:
> On Sun, 27 Oct 2002, Brian Ingerson wrote:
> 
> > FYI. (NOTE: Even though this seems like a competitive module, I
> > really think that Module::Build and CPAN::MakeMaker are somewhat
> > orthoganal. I'm looking forward to working together. There is a good
> > chance that these modules could nicely complement each other. Let the
> > thinking begin :)
> 
> I like that self-instaling feature.  I wonder if we could/should
> incorporate that for Module::Build.
> 
> Maybe we could offer a 'Build uberdist' feature or something that would
> simply incorporate all of the M::B files into the tarball.  As long as
> they end up untarring into the top-level of the distro (./Module,
> ./Module/Base.pm, etc) it'd just work.

You have to make sure that an *installed* copy of M::B reloads the local
copy. The installed version will always be found first. But ultimately,
it's the local copy you want to execute, because that is the one that
the module author configured his distribution for. This is *essential*.
If you do it, you'll never have versioning problems. If you don't you'll
be plagued by them.

One problem the current M::B faces is that it not only needs to get a
copy of M::B on every install (an extremely formidable task in its own
right) it also needs to have a compatible version of itself everywhere.
How do you advance? CPAN::MM skirts around this nicely.

If you do the self install route, you have one other issue to tackle.
What happens to all the existing M::B installs? They don't know how to
play the game. They must be removed, or you must change your module
name. I ran into this problem with Inline::MakeMaker, the precedent to
C::MM. I was going to need to find a way to nuke the old ones. Now I'm
saved by the fact that I can move all the planned Inline logic into
C::MM which doesn't (and won't) have legacy problems.

Most importantly, if you go this route, please don't put M::B in core
Perl. It would be completely illogical, and offer no advantage.

> This could even be the default for Module::Build.  Think how freaking cool
> this would be!  M::B would _just work_, whenever an author chose to use
> it.  This would also mean they could always use a minimal passthrough
> Makefile.PL and know it'd work with existing versions of CPAN.pm and
> future versions (and CPANPLUS too).

I can see a world where authors could choose either M::B or C::MM, or even
both simultaneously!

> Some of the other (todo) features would be nice too, like handling
> bundling of other modules and support for making PPMs.

And it be nicer still if there were a way to share this code. For
instance an author could download a bundling plugin that supported both
M::B and C::M and that code would get stuffed into their distribution
automatically.

See Ken? We shoulda spent more time talking and less time having fun at OSCon
;)

Cheers, Brian

Re: [Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Dave R. <au...@ur...>]

On Sun, 27 Oct 2002, Brian Ingerson wrote:

> FYI. (NOTE: Even though this seems like a competitive module, I
> really think that Module::Build and CPAN::MakeMaker are somewhat
> orthoganal. I'm looking forward to working together. There is a good
> chance that these modules could nicely complement each other. Let the
> thinking begin :)

I like that self-instaling feature.  I wonder if we could/should
incorporate that for Module::Build.

Maybe we could offer a 'Build uberdist' feature or something that would
simply incorporate all of the M::B files into the tarball.  As long as
they end up untarring into the top-level of the distro (./Module,
./Module/Base.pm, etc) it'd just work.

This could even be the default for Module::Build.  Think how freaking cool
this would be!  M::B would _just work_, whenever an author chose to use
it.  This would also mean they could always use a minimal passthrough
Makefile.PL and know it'd work with existing versions of CPAN.pm and
future versions (and CPANPLUS too).

Some of the other (todo) features would be nice too, like handling
bundling of other modules and support for making PPMs.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

[Module-build-general] ANNOUNCE: CPAN-MakeMaker-0.10

[Brian I. <in...@tt...>]

Ken and friends,

FYI. (NOTE: Even though this seems like a competitive module, I
really think that Module::Build and CPAN::MakeMaker are somewhat
orthoganal. I'm looking forward to working together. There is a good
chance that these modules could nicely complement each other. Let the
thinking begin :)

Cheers, Brian

CPAN/MakeMaker version 0.10
===========================

The module ExtUtils::MakeMaker is familiar to everybody. It's on the
first line of every Makefile.PL of every module distribution on CPAN.

The good thing about ExtUtils::MakeMaker is that it is powerful,
featureful, flexible, cross-platform and on virtually every installation
of Perl 5. The bad thing about this legacy workhorse is that the Perl
community is crippled to significantly improve it. Any features added
now can only enhance the current release of Perl. Authors would shun new
features anyway, because their modules could not be used in earlier
versions of Perl that account for the overwhelming majority of
installations.

Unfortunately, ExtUtils::MakeMaker is also stuck with a suboptimal
interface for new Perl authors. Writing a good Makefile.PL requires an
unnecessary level of expertise. Although anything is possible, some
seemingly simple tasks (like distributing scripts) involve a lot of
setup. Complicating the matter is the fact that there is no API for
accessing many of the powerful internals of ExtUtils::MakeMaker.

CPAN::MakeMaker changes everything.

This module is a drop-in replacement for ExtUtils::MakeMaker.
CPAN::MakeMaker works exactly like its legacy counterpart, but it makes
a lot of simple things easier, and some harder things possible.

CPAN::MakeMaker is a self-distributing module. Only the people who want
to create a Perl module or script distribution need to install it. The
first time you run your Makefile.PL, CPAN::MakeMaker will attach itself
to your distribution. The people who end up installing your distribution
don't even need to have into on their system at all. It just works.

You should be able to switch any of your existing module distributions
to CPAN::MakeMaker by simply changing the line:

    use ExtUtils::MakeMaker;

to:

    use CPAN::MakeMaker;

And then run the command 'perl Makefile.PL'. Everything should
just work as before, but now you can take advantage of
CPAN::MakeMaker's additional features. See the CPAN::MakeMaker
documentation for more details.

Make the Switch!

NEW FEATURES

    0.10:
      - Initial Release

INSTALLATION

To install this module type the following:

   perl Makefile.PL
   make
   make test
   make install

COPYRIGHT AND LICENCE

Copyright (C) 2002 Brian Ingerson

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself. 

[Module-build-general] make install busted on OS X

[Brian I. <in...@tt...>]

OS X has a file system that is case insensitive. Due to the fact that
you have a file called INSTALL, you should really add the following line
to your Makefile:

    .PHONY: install

Otherwise the file dependency is always satisfied and 'make install'
does nothing.

Cheers, Brian

[Module-build-general] respect setting of sitelib

[Dave R. <au...@ur...>]

This fixes a bug where Module::Build doesn't respect setting of sitelib


--- Base.pm~	Fri Aug 23 03:45:11 2002
+++ Base.pm	Fri Oct 25 16:29:58 2002
@@ -789,8 +789,8 @@
   my ($self, $blib) = @_;
   my $lib  = File::Spec->catfile($blib,'lib');
   my $arch = File::Spec->catfile($blib,'arch');
-  return {$lib  => $self->{config}{sitelib},
-	  $arch => $self->{config}{sitearch},
+  return {$lib  => $self->{args}{sitelib} || $self->{config}{sitelib},
+          $arch => $self->{args}{sitelib} || $self->{config}{sitearch},
 	  read  => ''};  # To keep ExtUtils::Install quiet
 }

[Module-build-general] Re: 2 things

[Dave R. <au...@ur...>]

On Sun, 13 Oct 2002, Autrijus Tang wrote:

> > 2. I just noticed ExtUtils::AutoInstall.  Have you considered integrating
> > its functionality into Module::Build?
>
> Yes. I've given it some thoughts but no code yet.  M::B certainly
> could use a run-time detection of dependencies and autoinstallation.
> I need to play with Build.PL some more to figure out the neccessary
> hooks (that would also work under M::B::Compat mode).

There's already some cool prereq checking code in M::B.  Right now M::B
breaks things up along these lines:

  requires (core/all features lumped together)
  recommends (presumably for a feature)
  build_requires

I like EU::AI's notion of features though, which takes this one step
further and breaks it up by feature.  I think a good breakdown might be:

 core
 feature1
 feature2
 ...

with each of those in turn specifying runtime, build & test prereqs.

Combine this with M::B's current flexible specification syntax:

 'Foo::Bar' => '>= 1.2, != 1.9, <= 2.0'

and you have a pretty powerful way to handle prereqs.

I also like EU::AI's idea of associating tests with features, as well as
the additional make targets it implements.

Of course, I think M::B should still accept a simple version too:

  requires => { 'Foo::Bar' => 1.2 }

should just assign that to 'core', and maybe test & build as well, on the
assumption that if we're not told otherwise, we should just assume it
could be needed anywhere.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] A better passthrough Makefile.PL

[Dave R. <au...@ur...>]

On Sun, 13 Oct 2002, Autrijus Tang wrote:

> >   unless (eval { require Module::Build::Compat; 1 }) {
>
> This may very well pass whilst the M::B requirement (0.11) exceeds
> the user's own version (0.10), a situation that occured to me today.
>
> Maybe should test for the minimal M::B version here?

Yep, good thinking.  That should probably test for 0.11 at least.
Something like:

  unless (eval { require Module::Build::Compat; Module::Build->VERSION(0.11) ? 1 : 0 })

or something like that.

> >       my $yn = ExtUtils::MakeMaker::prompt( '  Install Module::Build', 'y' );
> >       if ($yn =~ /^y(es)?/i) {
> > 	  # save this cause CPAN will chdir all over the place.
> > 	  my $cwd = cwd();
> > 	  my $makefile = File::Spec->rel2abs($0);
> > 	  require CPAN;
> > 	  CPAN->install('Module::Build');
>
> This is largely a skeletal rework of ExtUtils::AutoInstall
> functionalities.  Are you interested with the idea that I work
> a M::B compatibility layer into EU::AI, and for the bootstrap
> code to include the EU::AI bootstrap code that, in addition
> to fetch M::B automatically, also installs the prereqs
> at 'Build' time?

Actually, what I was thinking of was putting chunks (all?) of EU::AI into
Module::Build somehow.  Given that M::B will (I really hope) end up in the
core for 5.10, I think this makes the most sense.  My goal re: M::B is to
help it become a much easier to use, more featureful replacement for
EU::MakeMaker.

In addition, I think it works really well as a generic _application_
installer.  For example, the example web site for the MasonBook is
distributed with a Build.PL that besides just installing a couple modules,
also does the following:

1. Asks the user where to install the Mason components.
2. Asks about how to connect to the RDBMS to be used for the site.
3. When 'Build install' is run, it installs the Mason components _and_
sets up the database (with Alzabo's help), including inserting some
default data (like categories and an admin user).


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

Re: [Module-build-general] A better passthrough Makefile.PL

[Autrijus T. <aut...@au...>]

On Thu, Oct 03, 2002 at 06:54:15PM -0500, Dave Rolsky wrote:
>   unless (eval { require Module::Build::Compat; 1 }) {

This may very well pass whilst the M::B requirement (0.11) exceeds
the user's own version (0.10), a situation that occured to me today.

Maybe should test for the minimal M::B version here?

>       my $yn = ExtUtils::MakeMaker::prompt( '  Install Module::Build', 'y' );
>       if ($yn =~ /^y(es)?/i) {
> 	  # save this cause CPAN will chdir all over the place.
> 	  my $cwd = cwd();
> 	  my $makefile = File::Spec->rel2abs($0);
> 	  require CPAN;
> 	  CPAN->install('Module::Build');

This is largely a skeletal rework of ExtUtils::AutoInstall
functionalities.  Are you interested with the idea that I work
a M::B compatibility layer into EU::AI, and for the bootstrap
code to include the EU::AI bootstrap code that, in addition
to fetch M::B automatically, also installs the prereqs
at 'Build' time?

Thanks,
/Autrijus/