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

Re: [Module-build-general] [PATCH] Compiling under Windows

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

On Sunday, February 23, 2003, at 05:09  PM, Randy W. Sims wrote:

> I've included the complete file instead of a patch since the original 
> is just an empty skeleton file. M::B now successfully compiles under 
> Windows, and it passes all tests (most of the time, see below).

Awesome, thanks!

> It could stand to be tightened up a bit, but I said I'd submit it by 
> the weekend, and I'm pretty much out of time :). It works fine; it's 
> just that there is some duplication of code which could probably be 
> eliminated.

That can wait until the future.  To do this cleanly, I think we could 
create a module like ExtUtils::C with classes like 
ExtUtils::C::Compiler and ExtUtils::C::Linker that Module::Build could 
just use transparently.  Its purpose would be to compile and link 
things that will be linked in with Perl modules (not a general tool for 
arbitrary C code), using the same interface regardless of platform.

We could use that module in other situations too, like in the testing 
code for ExtUtils::ParseXS.

Probably the code you've written for Win32 and the code I wrote for 
Unix would be a good start toward such a module.  But given that the 
module doesn't exist yet, we'll just have to wait. =)

Also, I think a "uses-a" or "has-a" relationship to the compiler/linker 
would make more sense than the "is-a" relationship that's now in the 
M::B::P::Windows.pm code, but I understand that this was probably an 
easier way to get things written.


> It's a bit more code than I first anticipated, but I thought it might 
> be worthwile to take advantage of the fact that most compiler/linkers 
> can be scripted. When possible it writes compiler/linker options to a 
> file instead of the commandline; this will hopefully avoid problems 
> with some versions of the Windows shell that have limits on 
> commandline length. I've set this up so that an option can be easily 
> added to turn it on or off if desired.

Sounds good.

> Outstanding issues:
>
> The 'runthrough.t' test sometimes fails in random places at random 
> times. This is true with or without the modifications I've made. 
> Sometimes 2 tests fail, sometimes 5, sometimes ??, most of the time 
> none--It's completly unpredictable. It happens after ./build 
> (real)clean as often as it happens after back to back runs of ./build 
> test. I have not yet had a chance to look into it, but I'm pretty 
> certain of the cause. Windows seems to be extremely sensitive about 
> file operations. Sometimes a file gets locked (not always the same one 
> in this case), and it can no longer be accessed. This usually means 
> that a file handle was not explicitly closed or a tied file was not 
> untied, etc.

Yes, there were a couple of places I had to deal with this problem for 
the Win32 folks.  Are you using the latest CVS version of M::B, or the 
CPAN version?  The CVS version fixed a few things, but it's likely 
there are more instances of this problem lurking.  Is there any way to 
get an error message to tell you what file is in contention?


> Another place I ran into problems with locked files is with the 
> 'system()' call. My first stab at getting M::B to work was basically a 
> copy, paste, and edit of the 'compile_c()' and 'link_c()' routines in 
> Base.pm, with branches all over the place to handle differences in 
> compiler syntax. When passing a LIST to system(), It would compile, 
> but the next call to system() to invoke the linker would fail with an 
> 'access denied' error. If I joined the list into a single string it 
> would work (don't ask how long it took me to track that down to the 
> system() call).

Ack - I'm really trying to avoid system(STRING) calls, because I really 
don't want shell metachars involved anywhere.  Differences in shell 
behavior can open up a whole new can of worms I'm trying to avoid.


> At some point I decided to revisit the issue to figure out exactly 
> what was happening, unfortunatelly changing back to the LIST form now 
> works as expected--It has never failed with that error again. This was 
> after I restructured the code, so I can only assume... bah, I won't 
> assume anything.....

We'll just keep our eye on it, I guess.


> Under Windows, the ExtUtils::Mksymlist module is required to generate 
> a file that instructs the linker on what functions/variable to 
> export/import.

This dependency on Mksymlist (which I agree is necessary) is a good 
example of how prerequisites can vary based on the system, and suggests 
that the "mini-language" dependency syntax I wrote about last week is 
getting pretty important.  Otherwise we have to have dynamic dependency 
lists depending on the platform, which I don't like.


> Most of the time it is invoked with just the name of the module being 
> built, but sometimes it's neccessary to pass in lists of 
> functions/variables. I thought it would be best to leave it to you as 
> to  how the user will pass the information through. As it is, it 
> should work for most modules, and a small change to 'sub prelink()' 
> telling it where to get the user supplied options will allow it to 
> work those modules that need that extra functionality.
>

Okay, so people could override prelink_c() in their own subclasses?

> If the xs.t test fails to find a compiler, Shouldn't it NOT fail, but 
> simply notify the user that there is no compiler and that it will 
> operate in a degraded capacity, i.e. only installing pure perl > modules?

Yes, you're right.


> The first of the week is always pretty busy for me, but I'll try to 
> look into some of the outstanding issues later this week.

Great.  I think I'm going to push this release out before you have a 
chance to get to these issues, to let other people bang on it a little 
bit.  It's certainly way less broken now than it used to be, from the 
looks of things. =)

  -Ken

Re: [Module-build-general] PATCH: added ACTION_versioninstall

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

On 19/02/03 20:43 -0600, Ken Williams wrote:
> Applied!
> 
> I think the fact that $only::config::versionlib, 
> $only::config::versionarch, and @ARGV need to be manipulated 
> dynamically means that only.pm needs a little interface work, though - 
> do you plan on adding a programmatic interface that could just accept 
> this stuff as arguments?

And now for that patch I promised. Sorry I took so long, but you
challenged me to go back and refactor only.pm, which I did a whole bunch
of. I think you'll find the new patch to be much cleaner :)

I also am getting some interesting ideas on how to give C<only> an OO
API. Something like:

    use only YAML => '0.35';

could be:

    use only;
    my $o;
    BEGIN {
        $o = only->new;
        $o->module('YAML');
        $o->condition('0.35');
        $o->versionlib('/home/ingy/modules');
        $o->include;  # have object put itself into @INC
    }
    use YAML qw(:all);
    BEGIN {
        $o->exclude;  # remove itself from @INC
    }

Anyway, I digress. Here is your patch. I must admit I find it quite
powerful to say:

    perl Build.PL
    ./Build versioninstall versionlib=/home/ingy/foo

Cheers, Brian


diff -ru Module-Build-0.15-orig/lib/Module/Build/Base.pm Module-Build-0.15.only/lib/Module/Build/Base.pm
--- Module-Build-0.15-orig/lib/Module/Build/Base.pm	Fri Jan 17 12:53:11 2003
+++ Module-Build-0.15.only/lib/Module/Build/Base.pm	Sun Feb 23 17:56:55 2003
@@ -761,6 +761,14 @@
   ExtUtils::Install::install($self->install_map('blib'), 1, 1);
 }
 
+sub ACTION_versioninstall {
+  my ($self) = @_;
+  eval { require only::install };
+  die "You must have only.pm installed for this operation:\n$@" if $@;
+  $self->depends_on('build');
+  only::install::install(%{$self->{args}});
+}
+
 sub ACTION_clean {
   my ($self) = @_;
   foreach my $item (keys %{$self->{cleanup}}) {
diff -ru Module-Build-0.15-orig/lib/Module/Build.pm Module-Build-0.15.only/lib/Module/Build.pm
--- Module-Build-0.15-orig/lib/Module/Build.pm	Fri Jan 17 13:11:05 2003
+++ Module-Build-0.15.only/lib/Module/Build.pm	Wed Feb 19 16:46:26 2003
@@ -733,6 +733,28 @@
 anything, it will just report what it I<would> have done if you had
 actually run the C<install> action.
 
+=item versioninstall
+
+If you have C<only.pm> installed on your system, you can use this action
+to install a module into the version specific library trees. This means
+that you can have several versions of the same module installed and
+C<use> a specific one like this:
+
+ use only MyModule => 0.55;
+
+To override the default installation libraries in C<only::config>,
+specify the C<versionlib> parameter when you run the C<Build.PL> script:
+
+ perl Build.PL versionlib=/my/version/place/
+
+To override which version the module is installed as, specify the
+C<versionlib> parameter when you run the C<Build.PL> script:
+
+ perl Build.PL version=0.50
+
+See the C<only.pm> documentation for more information on version
+specific installs.
+
 =item manifest
 
 This is an action intended for use by module authors, not people
Only in Module-Build-0.15.only: x

Re: [Module-build-general] PATCH: make purge/remove Makefile

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

On 20/02/03 10:01 -0600, Ken Williams wrote:
> 
> On 19/02/03 21:27 -0800, Brian Ingerson wrote:
> > Here's another patch. I *always* use 'make purge' and I miss it in M::B
> > so I'm suggesting adding it. Very small change.
> 
> What's the precedent for that?  I don't see it in the EU::MM docs.

It's been in EU::MM forever.

  # --- MakeMaker realclean section:

  # Delete temporary files (via clean) and also delete installed files
  realclean purge ::  clean        rm -rf $(INST_AUTODIR) $(INST_ARCHAUTODIR)
          rm -rf $(DISTVNAME)
          rm -f  blib/lib/YAML.pod blib/lib/YAML.pm
          rm -rf Makefile Makefile.old

Just an alias for realclean. Just like in my patch!

> > I also noticed you weren't deleting the Makefile; a task that any
> > self-respecting realclean is expected to do :)
> 
> 'make realclean' already deletes the Makefile.  'Build realclean' 
> doesn't, because it knows nothing about it, since it's created by the 
> pass-through Makefile.PL.

oh

> Really, I think people need to start using the Build.PL directly 
> instead of relying on the pass-through Makefile.  It doesn't even 
> handle argument passing, for heaven's sake!

I wasn't trying to do things improperly. I was just testing all the
possibilities. Damn users! ;)

Cheers, Brian

[Module-build-general] [PATCH] Compiling under Windows

[Randy W. S. <Ra...@Th...>]

I've included the complete file instead of a patch since the original is 
just an empty skeleton file. M::B now successfully compiles under 
Windows, and it passes all tests (most of the time, see below). It could 
stand to be tightened up a bit, but I said I'd submit it by the weekend, 
and I'm pretty much out of time :). It works fine; it's just that there 
is some duplication of code which could probably be eliminated.

It's a bit more code than I first anticipated, but I thought it might be 
worthwile to take advantage of the fact that most compiler/linkers can 
be scripted. When possible it writes compiler/linker options to a file 
instead of the commandline; this will hopefully avoid problems with some 
versions of the Windows shell that have limits on commandline length. 
I've set this up so that an option can be easily added to turn it on or 
off if desired.

Outstanding issues:

The 'runthrough.t' test sometimes fails in random places at random 
times. This is true with or without the modifications I've made. 
Sometimes 2 tests fail, sometimes 5, sometimes ??, most of the time 
none--It's completly unpredictable. It happens after ./build (real)clean 
as often as it happens after back to back runs of ./build test. I have 
not yet had a chance to look into it, but I'm pretty certain of the 
cause. Windows seems to be extremely sensitive about file operations. 
Sometimes a file gets locked (not always the same one in this case), and 
it can no longer be accessed. This usually means that a file handle was 
not explicitly closed or a tied file was not untied, etc.

Another place I ran into problems with locked files is with the 
'system()' call. My first stab at getting M::B to work was basically a 
copy, paste, and edit of the 'compile_c()' and 'link_c()' routines in 
Base.pm, with branches all over the place to handle differences in 
compiler syntax. When passing a LIST to system(), It would compile, but 
the next call to system() to invoke the linker would fail with an 
'access denied' error. If I joined the list into a single string it 
would work (don't ask how long it took me to track that down to the 
system() call). At some point I decided to revisit the issue to figure 
out exactly what was happening, unfortunatelly changing back to the LIST 
form now works as expected--It has never failed with that error again. 
This was after I restructured the code, so I can only assume... bah, I 
won't assume anything.....

Under Windows, the ExtUtils::Mksymlist module is required to generate a 
file that instructs the linker on what functions/variable to 
export/import. Most of the time it is invoked with just the name of the 
module being built, but sometimes it's neccessary to pass in lists of 
functions/variables. I thought it would be best to leave it to you as to 
  how the user will pass the information through. As it is, it should 
work for most modules, and a small change to 'sub prelink()' telling it 
where to get the user supplied options will allow it to work those 
modules that need that extra functionality.

If the xs.t test fails to find a compiler, Shouldn't it NOT fail, but 
simply notify the user that there is no compiler and that it will 
operate in a degraded capacity, i.e. only installing pure perl modules?

The first of the week is always pretty busy for me, but I'll try to look 
into some of the outstanding issues later this week.

Randy.

Re: [Module-build-general] PATCH: make purge/remove Makefile

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

On 19/02/03 21:27 -0800, Brian Ingerson wrote:
> Here's another patch. I *always* use 'make purge' and I miss it in M::B
> so I'm suggesting adding it. Very small change.

What's the precedent for that?  I don't see it in the EU::MM docs.


>
> I also noticed you weren't deleting the Makefile; a task that any
> self-respecting realclean is expected to do :)

'make realclean' already deletes the Makefile.  'Build realclean' 
doesn't, because it knows nothing about it, since it's created by the 
pass-through Makefile.PL.

Really, I think people need to start using the Build.PL directly 
instead of relying on the pass-through Makefile.  It doesn't even 
handle argument passing, for heaven's sake!

  -Ken

Re: [Module-build-general] PATCH: make purge/remove Makefile

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

On 19/02/03 21:27 -0800, Brian Ingerson wrote:
> Here's another patch. I *always* use 'make purge' and I miss it in M::B
> so I'm suggesting adding it. Very small change.
> 
> I also noticed you weren't deleting the Makefile; a task that any
> self-respecting realclean is expected to do :)
> 
> Cheers, Brian

And here it is! :\


Only in Module-Build-0.15: .Makefile.PL.swp
diff -ru Module-Build-0.15-orig/lib/Module/Build/Base.pm Module-Build-0.15/lib/Module/Build/Base.pm
--- Module-Build-0.15-orig/lib/Module/Build/Base.pm	Fri Jan 17 12:53:11 2003
+++ Module-Build-0.15/lib/Module/Build/Base.pm	Wed Feb 19 21:21:15 2003
@@ -771,8 +771,13 @@
 sub ACTION_realclean {
   my ($self) = @_;
   $self->depends_on('clean');
-  $self->delete_filetree($self->{properties}{config_dir}, $self->{properties}{build_script});
+  $self->delete_filetree($self->{properties}{config_dir},
+                         $self->{properties}{build_script}, 
+                         'Makefile',
+                        );
 }
+
+*ACTION_purge = \&ACTION_realclean;
 
 sub ACTION_dist {
   my ($self) = @_;
diff -ru Module-Build-0.15-orig/lib/Module/Build.pm Module-Build-0.15/lib/Module/Build.pm
--- Module-Build-0.15-orig/lib/Module/Build.pm	Fri Jan 17 13:11:05 2003
+++ Module-Build-0.15/lib/Module/Build.pm	Wed Feb 19 20:47:18 2003
@@ -115,14 +115,15 @@
 'actions'.  In this case the actions run are 'build' (the default
 action), 'test', and 'install'.  Actions defined so far include:
 
-  build                          fakeinstall 
-  clean                          help        
-  diff                           install     
-  dist                           manifest    
-  distcheck                      realclean   
-  distclean                      skipcheck   
-  distdir                        test        
-  disttest                       testdb      
+  build                          help        
+  clean                          install     
+  diff                           manifest    
+  dist                           manifypods  
+  distcheck                      purge       
+  distclean                      realclean   
+  distdir                        skipcheck   
+  disttest                       test        
+  fakeinstall                    testdb      
 
 You can run the 'help' action for a complete list of actions.
 
@@ -694,6 +695,10 @@
 C<_build> directory and the C<Build> script.  If you run the
 C<realclean> action, you are essentially starting over, so you will
 have to re-create the C<Build> script again.
+
+=item purge
+
+An alias for realclean.
 
 =item diff
 

[Module-build-general] PATCH: make purge/remove Makefile

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

Here's another patch. I *always* use 'make purge' and I miss it in M::B
so I'm suggesting adding it. Very small change.

I also noticed you weren't deleting the Makefile; a task that any
self-respecting realclean is expected to do :)

Cheers, Brian

Re: [Module-build-general] PATCH: added ACTION_versioninstall

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

On 19/02/03 20:43 -0600, Ken Williams wrote:
> Applied!
> 
> I think the fact that $only::config::versionlib, 
> $only::config::versionarch, and @ARGV need to be manipulated 
> dynamically means that only.pm needs a little interface work, though - 
> do you plan on adding a programmatic interface that could just accept 
> this stuff as arguments?

Good point. That's pretty crufty. I'll fix it. Expect a patch later
tonight.

Cheers, Brian


> 
>   -Ken
> 
> On Wednesday, February 19, 2003, at 07:24  PM, Brian Ingerson wrote:
> 
> > Here's a patch to make:
> >
> >     ./Build versioninstall work.
> >
> > Cheers, Brian
> >
> >
> > diff -ru Module-Build-0.15-orig/lib/Module/Build/Base.pm 
> > Module-Build-0.15/lib/Module/Build/Base.pm
> > --- Module-Build-0.15-orig/lib/Module/Build/Base.pm	Fri Jan 17 
> > 12:53:11 2003
> > +++ Module-Build-0.15/lib/Module/Build/Base.pm	Wed Feb 19 17:01:52 2003
> > @@ -761,6 +761,28 @@
> >    ExtUtils::Install::install($self->install_map('blib'), 1, 1);
> >  }
> >
> > +sub ACTION_versioninstall {
> > +  my ($self) = @_;
> > +  eval { require only };
> > +  die "You must have only.pm installed for this operation\n"
> > +    if $@;
> > +
> > +  if (defined $self->{args}{versionlib}) {
> > +    require Config;
> > +    $only::config::versionlib = $self->{args}{versionlib};
> > +    $only::config::versionarch =
> > +      File::Spec->catdir($self->{args}{versionlib},
> > +                         $Config::Config{archname});
> > +  }
> > +  my @args = ();
> > +  if (defined $self->{args}{version}) {
> > +    push @args, $self->{args}{version};
> > +  }
> > +  $self->depends_on('build');
> > +  local @ARGV = @args;
> > +  only::install();
> > +}
> > +
> >  sub ACTION_clean {
> >    my ($self) = @_;
> >    foreach my $item (keys %{$self->{cleanup}}) {
> > diff -ru Module-Build-0.15-orig/lib/Module/Build.pm 
> > Module-Build-0.15/lib/Module/Build.pm
> > --- Module-Build-0.15-orig/lib/Module/Build.pm	Fri Jan 17 13:11:05 2003
> > +++ Module-Build-0.15/lib/Module/Build.pm	Wed Feb 19 16:46:26 2003
> > @@ -733,6 +733,28 @@
> >  anything, it will just report what it I<would> have done if you had
> >  actually run the C<install> action.
> >
> > +=item versioninstall
> > +
> > +If you have C<only.pm> installed on your system, you can use this 
> > action
> > +to install a module into the version specific library trees. This 
> > means
> > +that you can have several versions of the same module installed and
> > +C<use> a specific one like this:
> > +
> > + use only MyModule => 0.55;
> > +
> > +To override the default installation libraries in C<only::config>,
> > +specify the C<versionlib> parameter when you run the C<Build.PL> 
> > script:
> > +
> > + perl Build.PL versionlib=/my/version/place/
> > +
> > +To override which version the module is installed as, specify the
> > +C<versionlib> parameter when you run the C<Build.PL> script:
> > +
> > + perl Build.PL version=0.50
> > +
> > +See the C<only.pm> documentation for more information on version
> > +specific installs.
> > +
> >  =item manifest
> >
> >  This is an action intended for use by module authors, not people
> > Only in Module-Build-0.15: x
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> > The most comprehensive and flexible code editor you can use.
> > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> > www.slickedit.com/sourceforge
> > _______________________________________________
> > Module-build-general mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/module-build-general
> >
> 
>   -Ken

Re: [Module-build-general] PATCH: added ACTION_versioninstall

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

Applied!

I think the fact that $only::config::versionlib, 
$only::config::versionarch, and @ARGV need to be manipulated 
dynamically means that only.pm needs a little interface work, though - 
do you plan on adding a programmatic interface that could just accept 
this stuff as arguments?

  -Ken

On Wednesday, February 19, 2003, at 07:24  PM, Brian Ingerson wrote:

> Here's a patch to make:
>
>     ./Build versioninstall work.
>
> Cheers, Brian
>
>
> diff -ru Module-Build-0.15-orig/lib/Module/Build/Base.pm 
> Module-Build-0.15/lib/Module/Build/Base.pm
> --- Module-Build-0.15-orig/lib/Module/Build/Base.pm	Fri Jan 17 
> 12:53:11 2003
> +++ Module-Build-0.15/lib/Module/Build/Base.pm	Wed Feb 19 17:01:52 2003
> @@ -761,6 +761,28 @@
>    ExtUtils::Install::install($self->install_map('blib'), 1, 1);
>  }
>
> +sub ACTION_versioninstall {
> +  my ($self) = @_;
> +  eval { require only };
> +  die "You must have only.pm installed for this operation\n"
> +    if $@;
> +
> +  if (defined $self->{args}{versionlib}) {
> +    require Config;
> +    $only::config::versionlib = $self->{args}{versionlib};
> +    $only::config::versionarch =
> +      File::Spec->catdir($self->{args}{versionlib},
> +                         $Config::Config{archname});
> +  }
> +  my @args = ();
> +  if (defined $self->{args}{version}) {
> +    push @args, $self->{args}{version};
> +  }
> +  $self->depends_on('build');
> +  local @ARGV = @args;
> +  only::install();
> +}
> +
>  sub ACTION_clean {
>    my ($self) = @_;
>    foreach my $item (keys %{$self->{cleanup}}) {
> diff -ru Module-Build-0.15-orig/lib/Module/Build.pm 
> Module-Build-0.15/lib/Module/Build.pm
> --- Module-Build-0.15-orig/lib/Module/Build.pm	Fri Jan 17 13:11:05 2003
> +++ Module-Build-0.15/lib/Module/Build.pm	Wed Feb 19 16:46:26 2003
> @@ -733,6 +733,28 @@
>  anything, it will just report what it I<would> have done if you had
>  actually run the C<install> action.
>
> +=item versioninstall
> +
> +If you have C<only.pm> installed on your system, you can use this 
> action
> +to install a module into the version specific library trees. This 
> means
> +that you can have several versions of the same module installed and
> +C<use> a specific one like this:
> +
> + use only MyModule => 0.55;
> +
> +To override the default installation libraries in C<only::config>,
> +specify the C<versionlib> parameter when you run the C<Build.PL> 
> script:
> +
> + perl Build.PL versionlib=/my/version/place/
> +
> +To override which version the module is installed as, specify the
> +C<versionlib> parameter when you run the C<Build.PL> script:
> +
> + perl Build.PL version=0.50
> +
> +See the C<only.pm> documentation for more information on version
> +specific installs.
> +
>  =item manifest
>
>  This is an action intended for use by module authors, not people
> Only in Module-Build-0.15: x
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>

  -Ken

[Module-build-general] PATCH: added ACTION_versioninstall

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

Here's a patch to make:

    ./Build versioninstall work.

Cheers, Brian


diff -ru Module-Build-0.15-orig/lib/Module/Build/Base.pm Module-Build-0.15/lib/Module/Build/Base.pm
--- Module-Build-0.15-orig/lib/Module/Build/Base.pm	Fri Jan 17 12:53:11 2003
+++ Module-Build-0.15/lib/Module/Build/Base.pm	Wed Feb 19 17:01:52 2003
@@ -761,6 +761,28 @@
   ExtUtils::Install::install($self->install_map('blib'), 1, 1);
 }
 
+sub ACTION_versioninstall {
+  my ($self) = @_;
+  eval { require only };
+  die "You must have only.pm installed for this operation\n"
+    if $@;
+
+  if (defined $self->{args}{versionlib}) {
+    require Config;
+    $only::config::versionlib = $self->{args}{versionlib};
+    $only::config::versionarch = 
+      File::Spec->catdir($self->{args}{versionlib}, 
+                         $Config::Config{archname});
+  }
+  my @args = ();
+  if (defined $self->{args}{version}) {
+    push @args, $self->{args}{version};
+  }
+  $self->depends_on('build');
+  local @ARGV = @args;
+  only::install();
+}
+
 sub ACTION_clean {
   my ($self) = @_;
   foreach my $item (keys %{$self->{cleanup}}) {
diff -ru Module-Build-0.15-orig/lib/Module/Build.pm Module-Build-0.15/lib/Module/Build.pm
--- Module-Build-0.15-orig/lib/Module/Build.pm	Fri Jan 17 13:11:05 2003
+++ Module-Build-0.15/lib/Module/Build.pm	Wed Feb 19 16:46:26 2003
@@ -733,6 +733,28 @@
 anything, it will just report what it I<would> have done if you had
 actually run the C<install> action.
 
+=item versioninstall
+
+If you have C<only.pm> installed on your system, you can use this action
+to install a module into the version specific library trees. This means
+that you can have several versions of the same module installed and
+C<use> a specific one like this:
+
+ use only MyModule => 0.55;
+
+To override the default installation libraries in C<only::config>,
+specify the C<versionlib> parameter when you run the C<Build.PL> script:
+
+ perl Build.PL versionlib=/my/version/place/
+
+To override which version the module is installed as, specify the
+C<versionlib> parameter when you run the C<Build.PL> script:
+
+ perl Build.PL version=0.50
+
+See the C<only.pm> documentation for more information on version
+specific installs.
+
 =item manifest
 
 This is an action intended for use by module authors, not people
Only in Module-Build-0.15: x

Re: [Module-build-general] use only The::Finest => 1.23;

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

On 19/02/03 13:54 -0600, Ken Williams wrote:
> 
> On Wednesday, February 19, 2003, at 01:44  PM, Brian Ingerson wrote:
> 
> > On 19/02/03 11:00 -0600, Ken Williams wrote:
> >>
> >> On Wednesday, February 19, 2003, at 12:46  AM, Brian Ingerson wrote:
> >>
> >>>           # Only use MyModule if version is between 0.30 and 0.50
> >>>           # but not 0.36; or if version is >= to 0.55.
> >>>           use only MyModule => '0.30-0.50 !0.36 0.55-', qw(:all);
> >>
> >> I'm not sure I understand when the parts are and-ed together and when
> >> they're or-ed together.  The above seems to mean
> >>
> >>           (0.30-0.50 and !0.36) or 0.55-
> >>
> >> or maybe actually
> >>
> >>           (0.30-0.50 or 0.55-) and !0.36
> >
> > Aren't those the same? For what version would they have a different
> > effect?
> 
> For those numbers they're the same, but for different numbers they're 
> not:
> 
>      (0.30-0.60 and !0.55) or 0.50-
> 
> isn't the same as
> 
>      (0.30-0.60 or 0.50-) and !0.55
> 
> because version 0.55 fulfills the first spec, but not the second.

Yeah, but that's a fairly silly spec. You get what you deserve.

I just wanted a syntax that could specify any reasonable condition and
be clean. I think what I have works nicely for this use case.

Can you think of a specification that couldn't be stated using only.pm's
syntax?

---

I took a look at the M::B doc and found:

    '>= 1.2, != 1.5, < 2.0'

So how would you do things like:

    '0.50-0.70 !0.60-0.65 0.80-0.90 1.00-'

BTW, I was also happy to accomplish full functionality with just '-' and
'!'. I avoided the '>', '>=', '<', '<=', '!=', '==' and ','. YAGNI.

> > I guess I need a more formal phrasing. Ideas?
> >
> 
> I think both of us could benefit from listening to someone who's done 
> this kind of thing before, too.

I suppose. I'm all ears for better ideas.

Cheers, Brian

Re: [Module-build-general] use only The::Finest => 1.23;

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

On Wednesday, February 19, 2003, at 01:44  PM, Brian Ingerson wrote:

> On 19/02/03 11:00 -0600, Ken Williams wrote:
>>
>> On Wednesday, February 19, 2003, at 12:46  AM, Brian Ingerson wrote:
>>
>>>           # Only use MyModule if version is between 0.30 and 0.50
>>>           # but not 0.36; or if version is >= to 0.55.
>>>           use only MyModule => '0.30-0.50 !0.36 0.55-', qw(:all);
>>
>> I'm not sure I understand when the parts are and-ed together and when
>> they're or-ed together.  The above seems to mean
>>
>>           (0.30-0.50 and !0.36) or 0.55-
>>
>> or maybe actually
>>
>>           (0.30-0.50 or 0.55-) and !0.36
>
> Aren't those the same? For what version would they have a different
> effect?

For those numbers they're the same, but for different numbers they're 
not:

     (0.30-0.60 and !0.55) or 0.50-

isn't the same as

     (0.30-0.60 or 0.50-) and !0.55

because version 0.55 fulfills the first spec, but not the second.


> I guess I need a more formal phrasing. Ideas?
>

I think both of us could benefit from listening to someone who's done 
this kind of thing before, too.

  -Ken

Re: [Module-build-general] use only The::Finest => 1.23;

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

On 19/02/03 11:00 -0600, Ken Williams wrote:
> 
> On Wednesday, February 19, 2003, at 12:46  AM, Brian Ingerson wrote:
> > I've just released a module called 'only.pm' that allows people to
> > install multiple versions of various modules. It also lets them 'use'
> > specific versions.
> 
> I saw that flash by on the CPAN-recent list.  Looks good to me.  Glad 
> it cooperates with M::B, and a patch for more explicit support would be 
> welcome.  I'm not in an environment where I'd use it much, but I know 
> those environments do exist when tight controls are necessary.
> 
> The only reservation I have is that it introduces a new syntax for 
> version number specs, and M::B already has something similar but 
> different.  It's not really essential to use the same syntax, but maybe 
> some cooperation would be good.  Hopefully someone will have some good 
> ideas about it in response to my "mini-language" post from yesterday.
> 
> >           # Only use MyModule if version is between 0.30 and 0.50
> >           # but not 0.36; or if version is >= to 0.55.
> >           use only MyModule => '0.30-0.50 !0.36 0.55-', qw(:all);
> 
> I'm not sure I understand when the parts are and-ed together and when 
> they're or-ed together.  The above seems to mean
> 
>           (0.30-0.50 and !0.36) or 0.55-
> 
> or maybe actually
> 
>           (0.30-0.50 or 0.55-) and !0.36

Aren't those the same? For what version would they have a different
effect?

Basically every condition is ORed together, but complements are ANDed.
Complements also short circuit. From the doc:

    If a module version matches a complement, that version is
    immediately rejected without further inspection.

I guess I need a more formal phrasing. Ideas?

I'll take a look at M::B's syntax.

Cheers, Brian

Re: [Module-build-general] MakeMaker Is DOOMED!

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

On Wednesday, February 19, 2003, at 12:06  AM, Brian Ingerson wrote:

> On 17/02/03 14:09 -0600, Ken Williams wrote:
>>
>> Then there are the cases where in order to get something installed
>> correctly, I just can't manage to do the job properly using EU::MM, so
>> I have to turn to M::B.
>>
>> For many of my modules, I've been distributing with both a Makefile.PL
>> and a Build.PL, and before too long I'll probably turn the 
>> Makefile.PLs
>> into pass-throughs when it gets too hectic for me to manage both of
>> them.  But I won't do that for crucial modules until M::B is more
>> well-known and more widely distributed and tested.
>
> I agree with all this. I am definitely in favor of M::B over EU::MM. 
> And
> in a perfect world, every Perl module would use a perfect version of
> M::B that was installed on every installation of Perl. But we ain't
> there yet. The technical and social bootstrapping is going to be a long
> and winding road with many cats to shepard. I'm looking for ways to
> abstract over both systems to smooth the transition.

Sounds like exactly the way I feel too.

>> And what of the people who have been sending me bug reports that say
>> that M::B doesn't work right on Win32, even though I tested it fine on
>> my iBook?  Maybe at some future date we'll be able to make modules 
>> that
>> a) have no unspotted bugs, and b) have no cross-platform issues, but I
>> don't think we're there yet.
>
> Right. This is assuming a more mature M::B of course. But we're getting
> there relatively fast no?

Yeah, but you have to remember, it's Software.  It's always going to 
have problems.  We'll never actually get to Wally World. ;-)

  -Ken

Re: [Module-build-general] use only The::Finest => 1.23;

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

On Wednesday, February 19, 2003, at 12:46  AM, Brian Ingerson wrote:
> I've just released a module called 'only.pm' that allows people to
> install multiple versions of various modules. It also lets them 'use'
> specific versions.

I saw that flash by on the CPAN-recent list.  Looks good to me.  Glad 
it cooperates with M::B, and a patch for more explicit support would be 
welcome.  I'm not in an environment where I'd use it much, but I know 
those environments do exist when tight controls are necessary.

The only reservation I have is that it introduces a new syntax for 
version number specs, and M::B already has something similar but 
different.  It's not really essential to use the same syntax, but maybe 
some cooperation would be good.  Hopefully someone will have some good 
ideas about it in response to my "mini-language" post from yesterday.

>           # Only use MyModule if version is between 0.30 and 0.50
>           # but not 0.36; or if version is >= to 0.55.
>           use only MyModule => '0.30-0.50 !0.36 0.55-', qw(:all);

I'm not sure I understand when the parts are and-ed together and when 
they're or-ed together.  The above seems to mean

          (0.30-0.50 and !0.36) or 0.55-

or maybe actually

          (0.30-0.50 or 0.55-) and !0.36

but that's not obvious from the syntax.

  -Ken

Re: [Module-build-general] Ready for release 0.16?

[Randy W. S. <Ra...@Th...>]

On 2/18/2003 5:17 PM, Ken Williams wrote:
> Hi,
> 
> Because of the recent P5P postings & Dave's perl.com article, there's 
> been significant interest in rolling out a new CPAN release of M::B 
> fairly soon.  There are several bug fixes and new features (most notably 
> Module::Signature support, and the 'destdir' installation parameter, 
> which will allow Chip to make a Debian distro) that would be nice for 
> people to see rather than seeing what's in 0.15.
> 
> The known outstanding bugs are:
> 
>  * C compilation (the compile_c() and link_c() methods) are known to 
> fail with at least 1 or 2 of the supported compilers on Win32.  Randy 
> Sims has volunteered to work on a fix, but if he's unable to do so 
> fairly soon, I'm tempted to release it in its current state to get the 
> other fixes released (Win32 fixes for the Makefile.PL wrapper, for 
> example).

I hope to have this fixed in the next day or two, but depending on how 
my schedule works out it may be as late as this weekend. I have started 
on the fixes, and I don't expect them to take too much longer; testing 
is where most of the time will be involved. In addition to testing with 
the included test scripts, I'd also like to test against some M::B ready 
modules from CPAN (both XS & pure perl). Does anyone have a list of such 
modules?

Randy.

[Module-build-general] use only The::Finest => 1.23;

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

I've just released a module called 'only.pm' that allows people to
install multiple versions of various modules. It also lets them 'use'
specific versions.

It may be of interest to this group that only.pm has Module::Build
specific code. It installs modules built with either MM or M::B.

Also it would be keen if Ken could add support for:

    ./Build only-install

as a wrapper for:

    perl -Monly=install

with the advantage that if run with sudo, Module::Build would supply the
correct perl binary.

I'll submit a patch if you'd like.


Here is the doc:

  NAME
      only - Load specific module versions; Install many
  
  SYNOPSIS
          # Install version 0.30 of MyModule
          cd MyModule-0.30
          perl Makefile.PL
          make test
          perl -Monly=install    # substitute for 'make install' 
      
          # Only use MyModule version 0.30
          use only MyModule => '0.30';
  
          # Only use MyModule if version is between 0.30 and 0.50
          # but not 0.36; or if version is >= to 0.55.
          use only MyModule => '0.30-0.50 !0.36 0.55-', qw(:all);
  
          # Don't export anything!
          use only MyModule => '0.30', [];
  
          # Version dependent arguments
          use only MyModule =>
              [ '0.20-0.27', qw(f1 f2 f3 f4) ],
              [ '0.30-',     qw(:all) ];
  
  USAGE
          # Note: <angle brackets> mean "optional".
  
          # To load a specific module
          use only MODULE => 'CONDITION SPEC' <, ARGUMENTS>;
  
          # For multiple argument sets
          use only MODULE => 
              ['CONDITION SPEC 1' <, ARGUMENTS1>],
              ['CONDITION SPEC 2' <, ARGUMENTS2>],
              ...
              ;
  
          # To install an alternate version of a module
          perl -Monly=install <- VERSION>        # instead of 'make install'
  
  DESCRIPTION
      The "only.pm" facility allows you to load a MODULE only if it satisfies
      a given CONDITION. Normally that condition is a version. If you just
      specify a single version, 'only' will only load the module matching that
      version. If you specify multiple versions, the module can be any of
      those versions. See below for all the different conditions you can use
      with "only".
  
      "only.pm" will also allow you to load a particular version of a module,
      when many versions of the same module are installed. See below for
      instructions on how to easily install many different versions of the
      same module.
  
  CONDITION SPECS
      A condition specification is a single string containing a list of zero
      or more conditions. The list of conditions is separated by spaces. Each
      condition can take one of the following forms:
  
      * plain version
          This is the most basic form. The loaded module must match this
          version string or be loaded from a version directory that uses the
          version string. Mulitiple versions means one or the other.
  
              use only MyModule => '0.11';
              use only MyModule => '0.11 0.15';
  
      * version range
          This is two single versions separated by a dash. The end points are
          inclusive in the range. If either end of the range is ommitted, then
          the range is open ended on that side.
  
              use only MyModule => '0.11-0.12';
              use only MyModule => '0.13-';
              use only MyModule => '-0.10';
              use only MyModule => '-';       # Means any version
  
          Note that a completely open range (any version) is not the same as
          just saying:
  
              use MyModule;
  
          because the "only" module will search all the various version libs
          before searhing in the regular @INC paths.
  
          Also note that an empty string or no string means the same thing as
          '-'.
  
              # All of these mean "use any version"
              use only MyModule => '-';
              use only MyModule => '';
              use only 'MyModule';
  
      * complement version or range
          Any version or range beginning with a '!' is considered to mean the
          inverse of that specification. A complement takes precedence over
          all other specifications. If a module version matches a complement,
          that version is immediately rejected without further inspection.
  
              use only MyModule => '!0.31';
              use only MyModule => '0.30-0.40 !0.31-0.33';
  
      The search works by searching the version-lib directories (found in
      "only::config") for a module that meets the condition specification. If
      more than one version is found, the highest version is used. If no
      module meets the specification, then a normal @INC style "require" is
      performed.
  
      If the condition is a subroutine reference, that subroutine will be
      called and passed an "only" object. If the subroutine returns a false
      value, the program will die. See below for a list of public methods that
      may be used upon the "only" object.
  
  ARGUMENTS
      All of the arguments following the CONDITION specification, will be
      passed to the module being loaded.
  
      Normally you can pass an empty list to "use" to turn off Exporting. To
      do this with "only", use an empty array ref.
  
          use only MyModule => '0.30';       # Default exporting
          use only MyModule => '0.30', [];   # No exporting
          use only MyModule => '0.30', qw(export list);  # Specific export
  
      If you need pass different arguments depending on which version is used,
      simply wrap each condition spec and arguments with an array ref.
  
          use only MyModule =>
              [ '0.20-0.27', qw(f1 f2 f3 f4) ],
              [ '0.30-',     qw(:all) ];
  
  INSTALLING MULTIPLE MODULE VERSIONS
      The "only.pm" module also has a facility for installing more than one
      version of a particular module. Using this facility you can install an
      older version of a module and use it with the 'use only' syntax.
  
      It works like this; when installing a module, do the familiar:
  
          perl Makefile.PL
          make
          make test
  
      But instead of "make install", do this:
  
          perl -Monly=install
  
      This will attempt to determine what version the module should be
      installed under. In some cases you may need to specify the version
      yourself. Do the following:
  
          perl -Monly=install - 0.55
  
      NOTE: Also works with "Module::Build" style modules.
  
      NOTE: The "perl" you use for this must be the same "perl" as the one
      used to do "perl Makefile.PL" or "perl Build.PL". While this seems
      obvious, you may run into problems with "sudo perl -Monly=install",
      since the "root" account may have a different "perl" in its path. If
      this happens, just use the full path to your "perl".
  
  INSTALLATION LOCATION
      When you install the "only" module, you can tell it where to install
      alternate versions of modules. These paths get stored into
      "only::config". The default location to install things is parallel to
      your sitelib. For instance if your sitelib was:
  
          /usr/lib/perl5/site_perl
  
      "only" would default to:
  
          /usr/lib/perl5/version
  
      This keeps your normal install trees free from any potential
      complication with version modules.
  
      If you install version 0.24 and 0.26 of MyModule and version 0.26 of
      Your::Module, they will end up here:
  
          /usr/lib/perl5/version/0.24/My/Module.pm
          /usr/lib/perl5/version/0.26/My/Module.pm
          /usr/lib/perl5/version/0.26/Your/Module.pm
  
  HOW IT WORKS
      "only.pm" is kind of like "lib.pm" on Koolaid! Instead of adding a
      search path to @INC, it adds a search object to @INC. This object is
      actually the "only.pm" object itself. The object keeps track of all of
      the modules related to a given package installation, and takes
      responsibility for loading those modules. This is very important because
      if you say:
  
          use only Goodness => '0.23';
  
      and then later:
  
          require Goodness::Gracious;
  
      you want to be sure that the correct version of the second module gets
      loaded. Especially when another module is doing the loading.
  
  THE FINE PRINT ON VERSIONING
      The "only.pm" module loads a module by the following process:
  
       1) Look for the highest suitable version of the module in the version
          libraries specified in only::config.
   
       else:
   
       2) Do a normal require() of the module, and check to make sure the 
          version is in the range specified.
  
      It is important to understand that the versions used in these two
      different steps come from different places and might not be the same.
  
      In the first step the version used is the version of the "distribution"
      that the module was installed from. This is grepped out of the Makefile
      and saved as metadata for that module.
  
      In the second step, the version is taken from $VERSION of that module.
      This is the same process used when you do something like:
  
           use MyModule '0.50';
  
      Unfortunately, there is no way to know what the distribution version is
      for a normally installed module.
  
      Fortunately, $VERSION is usually the same as the distribution version.
      That's because the popular "VERSION_FROM" Makefile.PL option makes it
      happen. Authors are encouraged to use this option.
  
      The conclusion here is that "only.pm" usually gets things right. Always
      check %INC, if you suspect that the wrong versions are being pulled in.
      If this happens, use more 'use only' statements to pull in the right
      versions.
  
      One failsafe solution is to make sure that all module versions in
      question are installed into the version libraries.
  
  LOADING MULTIPLE MODULE VERSIONS (at the same time)
      You can't do that! Are you crazy? Well I am. I can't do this yet but I'd
      really like to. I'm working on it. If you have ideas on how this might
      be accomplished, send me an email. If you don't have a good idea, send
      me some coffee.
  
  BUGS AND CAVEATS
      *   There is currently no way to install documentation for multiple
          modules.
  
      *   This module only works with Perl 5.6.1 and higher. That's because
          earlier versions of Perl don't support putting objects in @INC.
  
  AUTHOR
      Brian Ingerson <IN...@cp...>
  
  COPYRIGHT
      Copyright (c) 2003. Brian Ingerson. All rights reserved.
  
      This program is free software; you can redistribute it and/or modify it
      under the same terms as Perl itself.
  
      See http://www.perl.com/perl/misc/Artistic.html
  

Re: [Module-build-general] MakeMaker Is DOOMED!

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

On 17/02/03 14:09 -0600, Ken Williams wrote:
> 
> On Monday, February 17, 2003, at 01:41  PM, Brian Ingerson wrote:
> > Not necessarily. It can create both the Makefile and the Build script,
> > and then cue the user what to do, especially on non-unix systems.
> >
> 
> Okay, that sounds reasonable.
> 
> 
> > It's a good experiment actually. Module::Build and Test::More are two
> > excellent modules that I will probably not use because of the "prereq
> > syndrome". I won't add prerequisites to a module unless it is crucial 
> > to
> > that module's behaviour. And while useful, M::B and T::M are not
> > crucial.
> 
> Sometimes they are crucial for some projects.  For example, some of my 
> modules have "recommended" dependencies that I can't express well using 
> MakeMaker.  Crypt::SKey needs either Digest::MD4 *or* Digest::MD5, and 
> it can optionally use Term::ReadKey to function as a simple SKey 
> command-line calculator.  But the module can be useful with only 
> Digest::MD4, for example, so using M::B's more flexible prerequisite 
> system means that the user will actually have *fewer* required prereqs 
> than under MakeMaker, even if they don't already have M::B installed.
> 
> Then there are the cases where in order to get something installed 
> correctly, I just can't manage to do the job properly using EU::MM, so 
> I have to turn to M::B.
> 
> For many of my modules, I've been distributing with both a Makefile.PL 
> and a Build.PL, and before too long I'll probably turn the Makefile.PLs 
> into pass-throughs when it gets too hectic for me to manage both of 
> them.  But I won't do that for crucial modules until M::B is more 
> well-known and more widely distributed and tested.

I agree with all this. I am definitely in favor of M::B over EU::MM. And
in a perfect world, every Perl module would use a perfect version of
M::B that was installed on every installation of Perl. But we ain't
there yet. The technical and social bootstrapping is going to be a long
and winding road with many cats to shepard. I'm looking for ways to
abstract over both systems to smooth the transition. I hope that one day
(not too far away) CP::MM is a wrapper over completely over M::B instead
of both systems.

  (EU) MakeMaker is Dead. Long live (CP) MakeMaker. ;)

> > And I won't have to worry about what versions of T::M and M::B support
> > my module's needs because "Hey,  it worked on my system, it almost
> > certainly will work everywhere else, because it's the exact same
> > version."
> 
> And what of the people who have been sending me bug reports that say 
> that M::B doesn't work right on Win32, even though I tested it fine on 
> my iBook?  Maybe at some future date we'll be able to make modules that 
> a) have no unspotted bugs, and b) have no cross-platform issues, but I 
> don't think we're there yet.

Right. This is assuming a more mature M::B of course. But we're getting
there relatively fast no?

> > If a later version of M::B or T::M is incompatible or broken, it will
> > have absolutely no effect on that module I wrote 10 years ago before I
> > left the Perl community altogether to pursue a fulltime career in Pizza
> > Delivery Management.
> 
> So, which do you think is more common: a) an unseen bug in a module 
> gets fixed in a future version, or b) a module with no bugs gets broken 
> in a future version?  I'd say it's a), and that CP::MM (as described, 
> at least) optimizes for the less common case instead of the more common 
> one, in a way that would annoy me as a developer or system maintainer.
> 
> I think that in the CP::MM project, it will be *crucial* to allow the 
> user to use an upgraded version of a module that they've installed more 
> recently than the one the developer provided in the bundle, for the 
> reasons I described above.  It's really just not true that "it worked 
> once for the developer" implies that "it will work for everyone else 
> now and forever".
> 
> Usually the way people deal with buggy code on their systems is to 
> upgrade things using bug-fix releases, but if you keep distributing 
> buggy versions cached in CPAN distros people are going to be awfully 
> upset.

I see what you are saying, but here's the deal: If a bug is found in a
bundled installation support module like T::M or M::B, and it is known
to be fixed in a later version, there is ONE EXACT POINT of contact in
the entire universe. And we know her email address by definition.

Email the (CP::MM using) module author and tell them to re-release with
the fixed version and the worldwide problem is fixed for everyone in one
fell swoop. And this will take the author all of 5 minutes to do.

No need to hunt down and inform the thousands of M::B installees with a
busted version.

So I'll have to disagree with you here. It is *crucial* that CP::MM
always respects its private environment. That is the central theme
of CP::MM.

---

Now, that said, an inquisitive young sysadmin could simply run:

    make reset
    perl Makefile.PL

And CP::MM would reset the distro as if that person were the author.
They could fiddle with it until it worked on their platform and then
report their findings back to the real author.

Cheers, Brian

PS I really do like/support Module::Build. Keep up the good work.

Re: [Module-build-general] Ready for release 0.16?

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

On Tuesday, February 18, 2003, at 07:53  PM, Autrijus Tang wrote:

> On Tue, Feb 18, 2003 at 04:29:49PM -0600, Dave Rolsky wrote:
>> That sounds fine to me.  I think this needs to be fixed in
>> Module::Signature, not in Module::Build.  But the functionality is 
>> still
>> useful.
>
> That sound file to me too.  This is just a quick note to say I'm
> following the discussion, it's just I can't get around to fix it
> until early next month, after the Taipei.pm's P3P conferences are
> settled.

No problem.  At some point I may want your feedback on the 
mini-language stuff I just proposed to the list, what with your 
experience on ExtUtils::AutoInstall.


>
> (Patches are, of course, highly welcome.)

Yeah, yeah. =)  Patches to my master's thesis, which is due in two 
days, are equally welcome! ;-)

  -Ken

[Module-build-general] A mini-language for dependencies?

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

Hey,

So, I think Dave was the first to suggest this, and now I'm thinking 
it's maybe the right way to go too.  I think we need a little boolean 
mini-language to express module dependencies.

The reasoning is that some modules have complicated dependencies that 
surpass even the capabilities of the current M::B system.  When this 
happens, the developer's only choice is to use perl code to set the 
dependencies dynamically based on querying the user, poking around in 
the environment (for instance, getting the version of perl or looking 
at $^O), or whatever.  This means that a comprehensive, static 
dependency mapping much harder to maintain, since each dynamic 
dependency creates an unknown blotch in the map.

Anything we can do to get these dependencies expressed in a static 
declarative structure, rather than in runtime perl code, will help with 
this kind of mapping.

Such a mini-language probably doesn't need to be very sophisticated - 
probably just needs to support arbitrary boolean combinations, and have 
a few things to represent things like the perl version and the 
operating system.

The mini-language would probably be the province of a new module called 
something like Module::Prereq or Module::Dependency, which 
Module::Build would depend on (and because of a chicken/egg problem, 
Module::Build can't actually use the mini-language to express this 
dependency ;-).

I don't have a lot of experience designing mini-languages, but I'm 
thinking it should do at least the following:

  * Allow arbitrary boolean combinations of dependency on arbitrary
    versions of modules

  * Allow declarative branching based on perl version or OS

  * Allow dependency specification based on feature sets, similar
    to the way ExtUtils::AutoInstall groups things

  * Let the author specify *why* a certain dependency is necessary,
    especially in the case of optional dependencies

Here's a first stab at an example - it doesn't fulfill all of the above 
criteria, and it's not very nice yet, but it could maybe get the ball 
rolling.

-----------------------------------------------------------------------
SUBRULES:
  $md = Crypt::MD5 | Crypt::MD4;  # Subrules use '$' sigil?

REQUIRES:
  perl 5.6.0;    # Version number by itself, means "minimum required"
  File::Basename
    purpose => "To compute basenames for foo-function";
  $md;             # As defined above
    (os  = 'Windows' & Archive::Tar 0.23)  # OS-dependent stuff
  | (os != 'Windows' & Archive::Tar 0.17)

RECOMMENDS:
  Term::ReadKey;

FEATURES:
  feature1 => {
    PURPOSE:
     "Allows you to use feature 1"
    REQUIRES:
     Foo::Bar
  }

-----------------------------------------------------------------------

Comments?  Is there some precedent for this that I should follow?

One thing I specifically *haven't* addressed is external dependencies, 
like libraries or shell commands.  I don't know whether we want to get 
into that stuff.

  -Ken

Re: [Module-build-general] Ready for release 0.16?

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

On Tue, Feb 18, 2003 at 04:29:49PM -0600, Dave Rolsky wrote:
> That sounds fine to me.  I think this needs to be fixed in
> Module::Signature, not in Module::Build.  But the functionality is still
> useful.

That sound file to me too.  This is just a quick note to say I'm
following the discussion, it's just I can't get around to fix it
until early next month, after the Taipei.pm's P3P conferences are
settled.

(Patches are, of course, highly welcome.)

Thanks,
/Autrijus/

Re: [Module-build-general] Ready for release 0.16?

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

On Tue, 18 Feb 2003, Ken Williams wrote:

>   * The Module::Signature support is still incomplete.  Or rather, the
> testing thereof is incomplete in that it'll fail rudely if someone has
> Module::Signature installed but doesn't have keys in their keychain.  I
> think I'll disable the testing of it for the time being.

That sounds fine to me.  I think this needs to be fixed in
Module::Signature, not in Module::Build.  But the functionality is still
useful.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

[Module-build-general] Ready for release 0.16?

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

Hi,

Because of the recent P5P postings & Dave's perl.com article, there's 
been significant interest in rolling out a new CPAN release of M::B 
fairly soon.  There are several bug fixes and new features (most 
notably Module::Signature support, and the 'destdir' installation 
parameter, which will allow Chip to make a Debian distro) that would be 
nice for people to see rather than seeing what's in 0.15.

The known outstanding bugs are:

  * C compilation (the compile_c() and link_c() methods) are known to 
fail with at least 1 or 2 of the supported compilers on Win32.  Randy 
Sims has volunteered to work on a fix, but if he's unable to do so 
fairly soon, I'm tempted to release it in its current state to get the 
other fixes released (Win32 fixes for the Makefile.PL wrapper, for 
example).

  * The Module::Signature support is still incomplete.  Or rather, the 
testing thereof is incomplete in that it'll fail rudely if someone has 
Module::Signature installed but doesn't have keys in their keychain.  I 
think I'll disable the testing of it for the time being.

Anything else?

  -Ken

Re: [Module-build-general] Cross-platform fixes for pass-through Makefile

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

Hi James,

Thanks for that analysis.  So it doesn't look like a problem on Win32 - 
it should be noted, however, that this kind of situation could still 
(at least theoretically) cause problems on a Unix platform, but I think 
perhaps our efforts will be better directed elsewhere.

  -Ken

On Monday, February 17, 2003, at 03:44  PM, James Freeman wrote:

> Hi Ken,
>
> RE: X:\My Perl\bin\perl.exe
>
> The default install of perl from Active State is X:\Perl so you would 
> have
> to actively change it to something that is basically totally broken 
> when you
> do the install. I did a test install into d:\my perl\bin\perl.exe and 
> there
> is no way with quoting or \ the space to get Perl to run on the command
> line. Anyone who did this would be forced to change it immediately as 
> you
> can't do anything with perl with it installed this way as you simply 
> can't
> shell into the interpreter on the console which is ~99% of the Win32 
> useage.
>
> I don't think this will be a real world problem.
>
> cheers
>
> James
>
> -----Original Message-----
> From: Ken Williams [mailto:ke...@ma...]
> Sent: 17 February 2003 21:20
> To: sc...@po...
> Cc: Dave Rolsky; mod...@li...; James
> Freeman
> Subject: Re: [Module-build-general] Cross-platform fixes for
> pass-through Makefile
>
>
>
> On Monday, February 17, 2003, at 01:17  PM, sc...@po... wrote:
>
>> On Mon, Feb 17, 2003 at 12:18:00PM -0600, Dave Rolsky wrote:
>>>> 	$^X -e unlink -e shift $makefile
>>>
>>>  unlink -e ???
>>
>> He's avoiding using quotes.  You're allowed to have multiple -e's on
>> the
>> command line.  They'll be joined with a space and run as a single
>> program.
>
> Right.  So this is just a more cross-platform way to do
>
> 	$^X -e "unlink shift" $makefile
>
> The only part of it that's still an issue, I think, is the $^X
> variable.  It might contain something like "/My Computer/foo/bar/perl",
> in which case I guess the shell invocation would think the command was
> "/My" with argument "Computer/foo/bar/perl".
>
>   -Ken
>
>
>
>

  -Ken

Re: [Module-build-general] Cross-platform fixes for pass-through Makefile

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

On Monday, February 17, 2003, at 03:55  PM, sc...@po... wrote:
> Heh.  Good luck.  I gave up on that.  nmake is particularly frustrating
> and brain dead about having any sane quoting rules for it.
>
> My attempt at a cross-platform perl one-liner generating tool is:
> ExtUtils::MM_Any->oneliner in 6.06_02.  I mostly gave up on trying
> to deal with paths to perl with spaces in it.

Good to know. =)  I'll probably punt on this issue for now, just 
because anyone with spaces in their perl pathname probably installed 
perl in a nonstandard place and will likely know how to deal with it 
(which will probably just be to use the Build.PL instead of the 
Makefile.PL, honestly, since M::B doesn't have this problem).

  -Ken