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