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

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Ron S. <ro...@de...>]

Hi Folks

> So by switching to Build.PL we dont actually gain anything but
> complexity and balkanization.

Also, I hope no-one's lost sight of the fact that some of us use 
home-grown CGI scripts to install modules, and don't want manually 
intervention during the installation process. I mention this just in 
case it happens to be relevant.

> I feel obliged to repeat what I said earlier. I think the
> Module::Build project and the CPANPLUS project are Good Things. I
> think that some of the implementation decisions are not such Good
> Things, and I worry that the impact of them over the long haul will
> be negative for both CPAN and for Module::Build.  Only time will
> tell if im right.

I second that.
-- 
Ron Savage, ro...@de... on 24/11/2003. Room EF 312
Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia
Phone: +61-3-9251 7067, Fax: +61-3-9251 7604
http://www.deakin.edu.au/~rons

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Norbert G. <no...@MP...>]

Hi Dave,

On Thu, Nov 20 2003, Dave Rolsky wrote:
> 
> I wrote a patch for CPAN.pm to add support for Module::Build.

is this patch available somewhere ?   I would like to patch CPAN at
our installation.  I have already applied your patch for
EU::ModuleMaker and I would like to do the same with CPAN.

Thank you in advance,

Norbert
-- 
+-------------------------------------------------------------------+
| Norbert E. Gruener           http://www.MPA-Garching.MPG.de/~nog/ |
| Max-Planck-Institut          <no...@MP...>            |
| fuer Astrophysik             PGP encrypted mail preferred         |
| PGPprint(RSA):  66 64 C0 D0 6F 1A 16 02  C2 C6 37 83 3A 5F 88 9B  |
| PGPprint(DH):  8B9A CB28 79DC 4C4F 5A0F  08A8 2771 2A99 A091 FBE8 |
| PGPprint(DSS): 8900 2CB4 F3D3 124F 7ED2  F681 EA2D 11CA BE19 6642 |
+-------------------------------------------------------------------+

Re: [Module::Build] have_c_compiler uncovers Windoze bug

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

On 11/2/2003 1:55 PM, Randy W. Sims wrote:

> On 10/30/2003 9:36 PM, Randy W. Sims wrote:
> 
>> Hi Ken,
>>
>> Version 1.220 of M::B::Base.pm uncovered a bug. On Windows, an 
>> executable requires different options to the linker than a dynamic 
>> library. Currently link_c() is configured strictly to produce 
>> libraries. A quick and perhaps naive fix is to introduce an optional 
>> paramater to link_c() to indicate the desired type of the output file. 
>> But, I want to wait as I've also been looking into porting to AT&T's 
>> U/WIN Unix on Windows environment 
>> <http://www.research.att.com/sw/tools/uwin/> (like Cygwin, and it is 
>> going to require implementing static linking (see "Static Linking of a 
>> new Perl Binary" in the MM docs). This might also involve changes to 
>> link_c(), but I'm not sure yet. I'll post more when I learn more and 
>> before I start patching. But it may be this weekend as I'm going to 
>> set up a new computer thats been collecting dust; I'm going to setup 
>> Debain linux, one of the BSDs, Windows 2000, & Windows 98, multiboot 
>> so that I'll have a good testing system.
>>
> 
> I didn't get to work on this as much as I had hoped, but I did get some 
> of the scaffolding in place for the static linking. I've attached it in 
> case you want to look it over to see where it's going. It may be toward 
> the middle of the week before I can get back to it.
> 

This (if not obvious by now) did not go as well as I hoped. The current 
architecture for compiling and linking will not currently support this 
addition without a lot of work, and before doing that I think it better 
to discuss options and see how you want to proceed.

We talked before about two sub-projects we both agreed would be good for 
Module::Build: 1) a compiler framework, and 2) a plugin framework. My 
current thinking is that both of these are part of the solution to this 
problem.

I think that the compiler framework should provide a low level interface 
for invoking the compiler/linker/etc in a unified manner. In other words 
it would define a standard set of options which it would then translate 
to the proper options to the underlying tool. This low level interface 
would rarely be used except by Module::Build itself.

The plugin framework would provide an architecture for creating 
"actions" and "builders" (helpers to construct actions). I think 
"builders" are the missing key to providing an easy, expandable, means 
of creating libraries. Thus the primary interface is one that focuses on 
what instead of how:

my $lib_action = Module::Build::Action::Builder::new_library(
   link_type => 'static',
   name      => 'XSTest',
   sources   => [ 'XSTest/XSTest.xs' ],
   use_perl  => 1, # indicates should use flags/defines from Config.pm
   ...
);

Module::Build::Action::find_by_name('code')->add_dependency($lib_action);

...

my $bin_action = Module::Build::Action::Builder::new_executable(
   name     => 'compilet',
   sources  => [ 'compilet.c' ],
   use_perl => 0,
   ...
);

my $cc_test = Module::Build::Action::Builder::new(
   name => 'cc_test',
   code => sub (
     $bin_action->exec;
     return -e $bin_action->outfile;
   )
);

sub have_c_compiler { return $cc_test->result }


Well, something like that. Will this work? Opinions? Suggestions?

I may try to experiment some more with the plugin aspect since it would 
seem to need to come first. I'll post a patch when I can, if your 
interested.

Regards
Randy.

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

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

On 11/21/2003 4:03 PM, Nick Ing-Simmons wrote:
> Nick Ing-Simmons <nic...@el...> writes:
> 
>>>>package MyModule;
>>>>use Module;
>>>>use base 'Module';
>>>>use Cwd;
>>
>>If you moved that above the use Module line then when Module.pm 
>>was compiled it would know Cwd::cwd was a function.
> 
> 
> Sorry I could not see wood for the trees!
> 
> What is happening is that in MyModule you 'use Cwd',
> which EXPORTS 'cwd' by default - so now there is a MyModule::cwd
> which is a legitimate over-ride of base class's version so...
> 
> You call MyModule->new which inherits from Module->new - so far so good.
> But then Module::new calls MyModule->cwd which is the imported one.
> So fix is: 
> 
> package MyModule;
> use Module;
> use base 'Module';
> use Cwd ();    # No imports!
> 
> Alternatively Module's new could do 
> 
> sub new {
>    my $p = shift;
>    Module->cwd;  # ignore override by derived class.   
> }
> 
> But that rather spoils it as a base class.
> 

Ok, both of these work. I see now where I was flawed in understanding 
this one.

Many thanks to Nick, Adi, and Yitzchak (May I ask how to pronounce your 
name?) for the explanations and solutions.

BTW, strictly speaknig, wouldn't this still be considered a bug, since 
the behaviour difers depending on platform.

-- 
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
                 - Alexander Pope

Re: [Module::Build] Re: Cwd::cwd() bug??? on Cygwin

[Yitzchak Scott-T. <sth...@ef...>]

On Fri, Nov 21, 2003 at 06:21:51AM -0500, "Randy W. Sims" <Ra...@Th...> wrote:
> >>># test.pl
> >>>package MyModule;
> >>>use Module;
> >>>use base 'Module';
> >>>use Cwd;
> >
> >
> >If you moved that above the use Module line then when Module.pm 
> >was compiled it would know Cwd::cwd was a function.
> 
> Tried that too. Removing it does work though, but that's not a solution; 
> it's not reasonable to tell clients that subclass your library not to 
> 'use Cwd'.

If your class provides a method foo(), it is reasonable to tell those who
subclass that defining a sub foo or importing one from elsewhere
into their class will override the base method foo().   

> I'm having a hard time grasping the order in which perl is interpreting 
> this. What is desired is that $p->cwd() call Module::cwd() which should 
> then forward the call to Cwd::cwd(). But no matter how I rearrange 
> things I can't coax the behavior I want.
> 
> I'm missing something simple here; I know it...

use Cwd (); ??

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

[Nick Ing-S. <ni...@in...>]

Nick Ing-Simmons <nic...@el...> writes:
>>> package MyModule;
>>> use Module;
>>> use base 'Module';
>>> use Cwd;
>
>If you moved that above the use Module line then when Module.pm 
>was compiled it would know Cwd::cwd was a function.

Sorry I could not see wood for the trees!

What is happening is that in MyModule you 'use Cwd',
which EXPORTS 'cwd' by default - so now there is a MyModule::cwd
which is a legitimate over-ride of base class's version so...

You call MyModule->new which inherits from Module->new - so far so good.
But then Module::new calls MyModule->cwd which is the imported one.
So fix is: 

package MyModule;
use Module;
use base 'Module';
use Cwd ();    # No imports!

Alternatively Module's new could do 

sub new {
   my $p = shift;
   Module->cwd;  # ignore override by derived class.   
}

But that rather spoils it as a base class.

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

[Enache A. <en...@rd...>]

On Sat, Nov 15, 2003 a.d., Randy W. Sims wrote:
> -----><8-----
> # Module.pm
> package Module;
> 
> sub new {
>   my $p = shift;
>   $p->cwd;
> }
> 
> sub cwd {
>   require Cwd;
>   Cwd::cwd;
> }
> 
> 1;
> -----><8-----
> # test.pl
> package MyModule;
> use Module;
> use base 'Module';
> use Cwd;
> 
> package main;
> MyModule->new;
> -----><8-----

That's because Cwd exports its 'cwd' sub by default, and so it messes
your "namespace".
('use Cwd' has the same effect as declaring a 'MyModule::cwd' sub).

Try
	use Cwd ();

Regards,
Adi

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

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

Nick Ing-Simmons wrote:
> Randy W. Sims <Ra...@Th...> writes:
> 
>>>sub cwd {
>>>  require Cwd;
>>>  Cwd::cwd;
> 
> 
> If you made that 
>      Cwd::cwd();
> 
> it would work. 

nope. I already tried that.

>>>}
>>>
>>>1;
>>>-----><8-----
>>>
>>>-----><8-----
>>># test.pl
>>>package MyModule;
>>>use Module;
>>>use base 'Module';
>>>use Cwd;
> 
> 
> If you moved that above the use Module line then when Module.pm 
> was compiled it would know Cwd::cwd was a function.

Tried that too. Removing it does work though, but that's not a solution; 
it's not reasonable to tell clients that subclass your library not to 
'use Cwd'.

I'm having a hard time grasping the order in which perl is interpreting 
this. What is desired is that $p->cwd() call Module::cwd() which should 
then forward the call to Cwd::cwd(). But no matter how I rearrange 
things I can't coax the behavior I want.

I'm missing something simple here; I know it...

>>>package main;
>>>MyModule->new;
>>>-----><8-----
>>>

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

[Nick Ing-S. <nic...@el...>]

Randy W. Sims <Ra...@Th...> writes:
>> 
>> sub cwd {
>>   require Cwd;
>>   Cwd::cwd;

If you made that 
     Cwd::cwd();

it would work. 

>> }
>> 
>> 1;
>> -----><8-----
>> 
>> -----><8-----
>> # test.pl
>> package MyModule;
>> use Module;
>> use base 'Module';
>> use Cwd;

If you moved that above the use Module line then when Module.pm 
was compiled it would know Cwd::cwd was a function.

>> 
>> package main;
>> MyModule->new;
>> -----><8-----
>> 

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

[Nick Ing-S. <nic...@el...>]

Randy W. Sims <Ra...@Th...> writes:
>On 11/15/2003 10:56 AM, Randy W. Sims wrote:
>> Ok, this might in fact be a Cygwin problem. Cygwin & Cwd. The following 
>> produces the error "Usage: Cwd::cwd() at Module.pm line 6." under Cygwin 
>
>Ok, I finally had a chance to look into this one. Finding the problem 
>was easy, but I don't know the proper solution. The problem seems to be 
>that Module::Build call cwd() with the object syntax which passes self 
>as an argument. In the perl sources (cygwin/cygwin.c), the builtin cwd 
>does this check:
>
>   if(items != 0)
>     Perl_croak(aTHX_ "Usage: Cwd::cwd()");
>
>and fails on Cygwin because apparently Cygwin is the only OS that 
>performs this check. What is the proper way to fix this? Is there a way 
>Module::Build could work around this problem?

Yes - it could use Cwd::cwd() as documented - call it as a function 
not a method!

>
>Randy.
>
>> -----><8-----
>> # Module.pm
>> package Module;
>> 
>> sub new {
>>   my $p = shift;
>>   $p->cwd;
>> }
>> 
>> sub cwd {
>>   require Cwd;
>>   Cwd::cwd;
>> }
>> 
>> 1;
>> -----><8-----
>> 
>> -----><8-----
>> # test.pl
>> package MyModule;
>> use Module;
>> use base 'Module';
>> use Cwd;
>> 
>> package main;
>> MyModule->new;
>> -----><8-----
>> 

Re: [Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Michael G S. <sc...@po...>]

On Thu, Nov 20, 2003 at 10:13:37AM -0600, Dave Rolsky wrote:
> > Well, I find it odd that it works the way it does. CPAN expects a
> > Makefile.PL. If an author doesnt bother to have makefile.pl created (my
> > understanding is that this is not default, I await correction) then the
> > module is not auto installable by a large cross section of the deployed
> > Perls out there. This is an odd decision about a system intended to replace
> > MakeMaker IMO.  Build.PL should disappear and be replaced entirely by
> > Makefile.pl.
> 
> I wrote a patch for CPAN.pm to add support for Module::Build.
> 
> To address your complain that Build.PL should be called Makefile.PL, if
> this were to happen, you'd then complain that Module::Build doesn't accept
> all the same options as EU::MM.  This is intentional, because many of the
> EU::MM options are implemented in a rather crufty way.  A good example is
> PREFIX.  Trying to duplicate this logic really isn't worth it, so Ken
> chose a much simpler way of doing local installs.

I'd more than agree.  MakeMaker's interface blows, and large parts of it
are undocumented.  A new build system that was saddled with reimplementing
that crappy interface would be extremely difficult, would never really
work like MM does and have most of the problems of MakeMaker.

M::B's done a really good job of emulating Makefile.PL so far, enough to
handle automated installations and the most common options, but its just
a backstop while the module installation utilities (CPAN, CPANPLUS, etc...)
and user community adjust to M::B.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
This Ring, no other, is made by the elves, 
Who'd pawn their own mother to grab it themselves.
Ruler of creeper, mortal, and scallop,
This is a sleeper that packs quite a wallop.
        -- "Bored of the Rings"

[Module::Build] Re: [PATCH] ExtUtils::Mksymlists undefined var ref & return value

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

On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
 > Perhaps what is needed is to update EU::Mksymlists to both export the
 > platform-specific
 > extensions as constants and return the canonical path to the written
 > file back to it's
 > caller so that link_c() in M::B can act more intelligently.
 >

Mksymlists() now returns the name of the file written. (Derived from the 
value of the FILE parameter plus an OS specific extension.)

On 11/18/2003 10:51 PM, Michael G Schwern wrote:
> On Tue, Nov 18, 2003 at 09:08:38PM -0500, Randy W. Sims wrote:
> 
>>I've updated James' update of my patch ;) There were some Windows 
>>problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 
> 
> 
> This would not surprise me.

Fixed reference to undefined variable on MSWin32 and OS2.

Randy.

[Module::Build] Re: Cwd::cwd() bug??? on Cygwin

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

On 11/15/2003 10:56 AM, Randy W. Sims wrote:
> Ok, this might in fact be a Cygwin problem. Cygwin & Cwd. The following 
> produces the error "Usage: Cwd::cwd() at Module.pm line 6." under Cygwin 

Ok, I finally had a chance to look into this one. Finding the problem 
was easy, but I don't know the proper solution. The problem seems to be 
that Module::Build call cwd() with the object syntax which passes self 
as an argument. In the perl sources (cygwin/cygwin.c), the builtin cwd 
does this check:

   if(items != 0)
     Perl_croak(aTHX_ "Usage: Cwd::cwd()");

and fails on Cygwin because apparently Cygwin is the only OS that 
performs this check. What is the proper way to fix this? Is there a way 
Module::Build could work around this problem?

Randy.

> -----><8-----
> # Module.pm
> package Module;
> 
> sub new {
>   my $p = shift;
>   $p->cwd;
> }
> 
> sub cwd {
>   require Cwd;
>   Cwd::cwd;
> }
> 
> 1;
> -----><8-----
> 
> -----><8-----
> # test.pl
> package MyModule;
> use Module;
> use base 'Module';
> use Cwd;
> 
> package main;
> MyModule->new;
> -----><8-----
> 

[Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Chris R. <ch...@dy...>]

On Thu, 20 Nov 2003, Orton, Yves wrote:

> Thats great. Did it get applied? Even if it did it still wont help those
> that cannot upgrade their CPAN or install modules will it?

If you can't install a new version of CPAN.pm, how can you install other
modules?  You're either maintaining your own person perl lib, or
installing modules for the entire system.

Might I say that you seem awfully convinced that the sky is falling with
this issue.  Module::Build works pretty well.  That's my opinion, and the
opinion of a lot of people that are smarter than me.  There are a few
rough edges with regards to compatibility with MakeMaker, but they aren't
as bad as you make them to be.

Regards.

-- 
Chris Reinhardt -- ch...@dy... -- http://www.dyndns.org/
I have hardly ever known a mathematician who was capable of reasoning.
            --Plato

[Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Orton, Y. <yve...@de...>]

> On Thu, 20 Nov 2003, Orton, Yves wrote:
> 
> > Well, I find it odd that it works the way it does. CPAN expects a
> > Makefile.PL. If an author doesnt bother to have makefile.pl created (my
> > understanding is that this is not default, I await correction) then the
> > module is not auto installable by a large cross section of the deployed
> > Perls out there. This is an odd decision about a system intended to
replace
> > MakeMaker IMO.  Build.PL should disappear and be replaced entirely by
> > Makefile.pl.
> 
> I wrote a patch for CPAN.pm to add support for Module::Build.

Thats great. Did it get applied? Even if it did it still wont help those
that cannot upgrade their CPAN or install modules will it?
 
> To address your complain that Build.PL should be called 
> Makefile.PL, if this were to happen, you'd then complain 
> that Module::Build doesn't accept all the same options 
> as EU::MM.  

Thats a little presumptious actually. First off im not complaining. I'm
making observations that are grounded in my own experience and what Ive
heard from others.  Second I would say that if Module::Build received an
option it couldnt handle then failing gracefully is better than outright
incompatibility.

To my mind having Module::Build work correctly with the 80%+ installations
out there (yeah yeah, lies, damned lies and statistics) and causing problems
for the remaining 20% is far superior result than having it only work with
less than 1% of the installations out there.

> This is intentional, because many of the EU::MM options are implemented 
> in a rather crufty way.  A good example is PREFIX.  Trying to duplicate 
> this logic really isn't worth it, so Ken chose a much simpler way of 
> doing local installs.

I know this decision was intentional. I also consider it to be foolish.
Sorry, I know thats harsh but there you go.

Lets consider the situation as we have it from the POV of a CPAN.pm user
without your patches (like me and the vast majority of production perl
instances out there).

1. CPAN downloads the dist unpacks it and either
  A. Finds no Makefile.PL, and crashes directly.
  B. Finds a Makefile.PL which is simply a passthrough to Module::Build and
Build.PL.
    i) CPAN passes special options to the Makefile.PL
    ii) where Module::Build either ignores them or dies with an error.

In what way is the superior to 

1. CPAN downloads the dist, unpacks it and
2. Runs Makefile.PL with some set of special options
3. Makefile.PL uses Module::Build and either ignores them or dies with an
error.

So by switching to Build.PL we dont actually gain anything but complexity
and balkanization.

Its a bad call, and when things start getting closer 5.10 I think this
subject will heat up quite a bit.

Regards,
Yves
I feel obliged to repeat what I said earlier. I think the Module::Build
project and the CPANPLUS project are Good Things. I think that some of the
implementation decisions are not such Good Things, and I worry that the
impact of them over the long haul will be negative for both CPAN and for
Module::Build.  Only time will tell if im right.

Re: [Module::Build] Data::FormValidator + Module::Build : local prefix install fails under linux

[Terrence B. <met...@ur...>]

Randy W. Sims wrote:

> On 11/17/2003 8:12 PM, Terrence Brannon wrote:
>
>> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : perl 
>> Makefile.PL PR\
>> EFIX=$PREFIX
>> /usr/bin/perl Build.PL config=prefix=/home/princepawn/install
>> Deleting _build
>> Creating custom builder _build/lib/Data/FormValidator/Builder.pm in 
>> _build/lib/\
>> Data/FormValidator
>> Checking whether your kit is complete...
>> Looks good
>> Deleting Build
>> Removed previous script 'Build'
>> Creating new 'Build' script for 'Data-FormValidator' version '3.14'
>> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : echo $PREFIX
>> /home/princepawn/install
>> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : make install
>> /usr/bin/perl Build install
>> Warning: You do not have permissions to install into 
>> /usr/local/share/perl/5.8.\
>> 0 at /usr/share/perl/5.8.0/ExtUtils/Install.pm line 114.
>> mkdir /usr/local/share/perl/5.8.0/Data: Permission denied at 
>> /usr/share/perl/5.\
>> 8.0/ExtUtils/Install.pm line 176
>> make: *** [install] Error 255
>> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : uname -a
>> Linux perlmonk.org 2.4.18 #12 Fri Sep 13 17:49:41 EDT 2002 i686 
>> GNU/Linux
>> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 :
>>
>
> Is this a M::B issue or a security issue? 


M::B issue ---

> I'm not that familiar with M::B's install code, so I honestly don't 
> know what should happen here. I install software as root when on *nix 
> so there is no problem. What does MakeMaker do? 

when you type perl Makefile.PL PREFIX=$PREFIX, you can install wherever 
$PREFIX is set to, as long as you have write permissions. I have done so 
with MakeMaker-style makefiles plenty of times on this Linux machine. 
But no dice with M::B.


> Can you install as root?

no, this is at www.perlmonk.org --- the perlmonks user site.

> Hopefully Ken will be back soon... ;)
>
> Randy.
>

[Module::Build] RE: ExtUtils::MakeMaker or Module::Build

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

On Thu, 20 Nov 2003, Orton, Yves wrote:

> Well, I find it odd that it works the way it does. CPAN expects a
> Makefile.PL. If an author doesnt bother to have makefile.pl created (my
> understanding is that this is not default, I await correction) then the
> module is not auto installable by a large cross section of the deployed
> Perls out there. This is an odd decision about a system intended to replace
> MakeMaker IMO.  Build.PL should disappear and be replaced entirely by
> Makefile.pl.

I wrote a patch for CPAN.pm to add support for Module::Build.

To address your complain that Build.PL should be called Makefile.PL, if
this were to happen, you'd then complain that Module::Build doesn't accept
all the same options as EU::MM.  This is intentional, because many of the
EU::MM options are implemented in a rather crufty way.  A good example is
PREFIX.  Trying to duplicate this logic really isn't worth it, so Ken
chose a much simpler way of doing local installs.


-dave

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

[Module::Build] RE: ExtUtils::MakeMaker or Module::Build

[Orton, Y. <yve...@de...>]

> > I dont know the logic behind using Build.pl instead of 
> makefile.pl, but the
> > fact that it doesnt create the later by defualt (or so I 
> have been told) is
> > in my eyes a serious mistake that will greatly reduce its 
> overall uptake in
> > the market.  And for those people releasing code without a 
> Makefile.pl, I
> > wonder at the point of putting such things on CPAN. (Others 
> such as Randal
> > Schwartz have said the same thing)
> 
> Module::Build has a compatibility feature that does in fact produce a 
> Makefile.PL file for distribution. In addition, you can have both a 
> Build.PL and a MakeMaker Makefile.PL if you want to go that route.

Well, I find it odd that it works the way it does. CPAN expects a
Makefile.PL. If an author doesnt bother to have makefile.pl created (my
understanding is that this is not default, I await correction) then the
module is not auto installable by a large cross section of the deployed
Perls out there. This is an odd decision about a system intended to replace
MakeMaker IMO.  Build.PL should disappear and be replaced entirely by
Makefile.pl.

But thats an argument I have no expectation of winning.
 
> > Another serious issue with Module::Build is that for the 
> last ages on Win32
> > it doesnt. Have a look at the transaction report of trying 
> to install it
> > (using itself) from CPAN.  It doesnt play nicely with 
> CPAN's prerequisite
> > system, (a Makefile.pl program would have caused CPAN to 
> autoload these
> > prerequisites on my system by default) and fails build.
> 
> Module::Build has worked on Windows since version 0.16 (it also now 
> works on Cygwin as of 0.21); I ported it. Unfortunately the latest 
> release (0.21) had some Windows bugs that I didn't catch 
> before it was 
> released. Despite this last release, I have found it to be 
> very stable.

Alas, I have yet to see a stable Win32 build. I do believe that you did one,
but.....

> I believe current releases of CPAN(PLUS)? do natively support 
> Build.PL files, but I don't use either of them. (I prefer manual
installs).

CPANPLUS may do, but i do not think that CPAN does. Even if the latest
version does, this doesnt help people who cant upgrade the version that was
distributed with their perl, and makes life really difficult for people who
"cant install modules".

If you cant install modules then the fact that Module::Build and CPANPLUS
exist isnt going to help you much. 

The issue here is backwards compatibility. If you want your code to install
accross a wide range of OS's and platforms and perl versions then using
Module::Build and expecting people to have CPANPLUS is not going to be a
winning proposition.

> 
> I'm not arguing; I just wanted to clarify a few points. ;) 
> Module::Build is a long way from being complete, but I think it's further 
> along than you think, and it's catching on relatively fast.

I think it would have caught on a LOT faster if the silly Build.PL decision
hadnt been made. Breaking the old stuff is ok once the new stuff has
sufficient market penetration. Breaking the old stuff from the get go just
means youll never have the market penetration to convince people its
worthwhile.

Frankly until Module::Build works seamlessly by default with plain old CPAN
I would advance the opinion that it will never replace MakeMaker, and
potentially in the long run leave the community divided, with those of us
who can using Module::Build and those of us who cant or need to ensure
backwards compatibility not.  I personally dont think that the balkanization
of CPAN is a fair price for the changes that Module::Build brings.

Now if a concerted effort was made to ensure that Module::Build easily
installed everywhere (as seen with the prerequisites and Win32 build failure
it does not) and that _every_ distribution produced by Module::Build was
installable via CPAN.pm then I would feel much more confident about its
future.

> 
> BTW, If you want to see who and what is using Build.PL, I generated a 
> report a while back at
http://sourceforge.net/mailarchive/forum.php?thread_id=3333245&forum_id=1090
5>

Cheers, Ill have a look at it.

Yves

[Module::Build] Re: ExtUtils::MakeMaker or Module::Build

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

Orton, Yves wrote:
>>>But as we start to put this together we run across 
>>
>>Module::Build.  In
>>
>>>the past I have always used ExtUtils::MakaMaker.  Is there 
>>
>>a preference
>>
>>>(if one were starting from scratch), to using one over the other?
> 
> 
> Personally my feeling is that Module::Build isn't mature enough for release
> ready code.
> 
> The fact that without manual intervention what it produces isnt compatible
> with CPAN is IMO a serious argument against using it, and poses serious
> questions in my mind about its suitability in 5.10.  Luckily it will be a
> long time before 5.10 is released, so Ken has lots of time to get it right.
> 
> BTW, it shouldnt be seen that I am critical of Kens efforts, I actually
> think his project is quite a good idea and will eventually be an excellent
> replacement for older tools. But IMO it is not production worthy code at the
> current time.
> 
> I dont know the logic behind using Build.pl instead of makefile.pl, but the
> fact that it doesnt create the later by defualt (or so I have been told) is
> in my eyes a serious mistake that will greatly reduce its overall uptake in
> the market.  And for those people releasing code without a Makefile.pl, I
> wonder at the point of putting such things on CPAN. (Others such as Randal
> Schwartz have said the same thing)

Module::Build has a compatibility feature that does in fact produce a 
Makefile.PL file for distribution. In addition, you can have both a 
Build.PL and a MakeMaker Makefile.PL if you want to go that route.

> Another serious issue with Module::Build is that for the last ages on Win32
> it doesnt. Have a look at the transaction report of trying to install it
> (using itself) from CPAN.  It doesnt play nicely with CPAN's prerequisite
> system, (a Makefile.pl program would have caused CPAN to autoload these
> prerequisites on my system by default) and fails build.

Module::Build has worked on Windows since version 0.16 (it also now 
works on Cygwin as of 0.21); I ported it. Unfortunately the latest 
release (0.21) had some Windows bugs that I didn't catch before it was 
released. Despite this last release, I have found it to be very stable.

>>There are nearly 200 distinct distributions on CPAN that now use 
>>Module::Build. And the number continues to inch upward. M::B is 
>>scheduled to appear in perl 5.10 and ultimately to replace MakeMaker, 
>>see perldelta. M::B doesn't require a make tool, so on 
>>platforms that do not include easy access to make, users can still build
> 
> and 
> 
>>install pure perl modules.
> 
> 
> I agree that the makeless make is a worthy objective, and Kens efforts are
> to be applauded. But IMO currently its a bit of a waste that these modules
> use it and are on CPAN. First off this means that they are unavailable to
> Win32 users, a group that make up the majority of the Perl user base
> (whatever the *nixens think). And for those that havent bothered including
> Makefile.pl's and only Build.pl's, well that code wont install cleanly from
> the cpan shell.
> 
> Anyway,
> thats my take on using Module::Build.
> 
> Yves
> 

I believe current releases of CPAN(PLUS)? do natively support Build.PL 
files, but I don't use either of them. (I prefer manual installs).

I'm not arguing; I just wanted to clarify a few points. ;) Module::Build 
is a long way from being complete, but I think it's further along than 
you think, and it's catching on relatively fast.

BTW, If you want to see who and what is using Build.PL, I generated a 
report a while back at 
<http://sourceforge.net/mailarchive/forum.php?thread_id=3333245&forum_id=10905>

Regards,
Randy.

Re: [Module::Build] (RFC) META.yml Specification Update

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

Hi Ken,

Ok, this is the last time. I promise. 'Cause now I'm just talking to 
myself anyway.

Actually, I was doing some more hunting and gathering, and I stumbled 
across some other "suggestions". I also added to each field some tags 
indicating the version of the spec when the field was added and whether 
it's required or optional. (Thought about adding a tag for type, e.g. 
scalar, sequence, or mapping, but...)

I don't actually anticipate all these being added; this is basically an 
accumulation of ideas, current practice, brain-storm, etc. I've just 
tried to organize it for easy review. Cut and dice.

Notes and Sources:

The "authored_by" and "abstract" fields where added because I found 
quite a few META.yml files containing them or something like.

The "generation" field was added based on a discussion beginning here 
<http://nntp.x.perl.org/group/perl.cpan.discuss/1>, specifically 
<http://nntp.x.perl.org/group/perl.cpan.discuss/14>. Also, it surfaced 
again in this discussion 
<http://nntp.x.perl.org/group/perl.cpan.discuss/26>.

The "private" and "no_index" comes from a discussion began here 
<http://nntp.x.perl.org/group/perl.module-authors/765>, specifically 
<http://nntp.x.perl.org/group/perl.module-authors/800>. The "private" 
field was used unofficially for a while, but has since been changed to 
"no_index" as per 
<http://nntp.x.perl.org/group/perl.module-authors/1385> and 
<http://cplan.kwiki.org/?MinutesAccordingToAutrijus>

The "requires_package" field was first suggested by me in this brief 
discussion <http://nntp.x.perl.org/group/perl.module-authors/1313> and 
then shortly after in a much larger discussion 
<http://nntp.x.perl.org/group/perl.module-authors/1338> which is where I 
also added "requires_os", "excludes_os", and "configure" fields. Much of 
this is meant to aid cpan-testers automated testing, but will also be 
usefule for M::B, MM, and other tools.

The "require_build_tools" was added as another after-thought to the 
above because it also indicates an external dependency.

The alternative suggestion in "recommends" is another idle suggestion of 
mine which is meant to supply enough information to the user so that he 
or she can make an informed choice as to which optional modules to install.

I put it in pod 'cause it's easier to edit, and it's easy to change the 
format with pod2html and kin.

I've now finished my hunting and gathering period; it's time to evolve.

Later,
Randy.

Re: [Module::Build] Problem building XS modules on AIX

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

On 11/19/2003 5:48 PM, James.FitzGibbon wrote:

> It works to build Pod::Coverage 0.12 on AIX, but the M::B XS test itself
> fails.  It only fails two of ten tests, and those are related to
> cleanup:
> 
> t/xs............ok 8/10Can't remove directory blib/arch/auto/XSTest: Do
> not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib/arch/auto: Do not specify an existing file.
> at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib/arch: Do not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> Can't remove directory blib: Do not specify an existing file. at
> /home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
> line 1792
> # Test 9 got: 'Couldn't remove 'blib': Do not specify an existing file.
> ' (t/xs.t at line 72)
> #   Expected: ''
> # Failed test 10 in t/xs.t at line 75
> t/xs............FAILED tests 9-10
>         Failed 2/10 tests, 80.00% okay
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> ------------------------------------------------------------------------
> -------
> t/xs.t                    10    2  20.00%  9-10
> 1 test skipped.
> Failed 1/10 test scripts, 90.00% okay. 2/157 subtests failed, 98.73%
> okay.
> 
> The test code is:
> 
> eval {$m->dispatch('realclean')};
> ok $@, '';
> 
> # Make sure blib/ is gone after 'realclean'
> ok not -e 'blib';
> 
> So, this may not be the fault of the patch but instead bad assumptions
> on
> the part of the test.  On the other hand, this same test passed with the
> second revision of the patch (the current one being #3 I believe).
> 
> It may also be related to me running the test on an NFS mounted homedir.
> I tried it on a local disk and it passed.  So, I'm willing to write off
> the
> failures to the assumptions of the test suite and say it's a good
> candidate for
> then next release unless someone has an OS/2 or VMS box to pound on it
> with.
> 
> Thanks to everyone who helped.
> 

Ok, so this is likely a problem with delete_filetree in M::B::Base on 
NFS. I no nothing of NFS, so I'll get off at this station...

Randy.

Re: [Module::Build] Data::FormValidator + Module::Build : local prefix install fails under linux

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

On 11/17/2003 8:12 PM, Terrence Brannon wrote:
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : perl 
> Makefile.PL PR\
> EFIX=$PREFIX
> /usr/bin/perl Build.PL config=prefix=/home/princepawn/install
> Deleting _build
> Creating custom builder _build/lib/Data/FormValidator/Builder.pm in 
> _build/lib/\
> Data/FormValidator
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Data-FormValidator' version '3.14'
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : echo $PREFIX
> /home/princepawn/install
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : make install
> /usr/bin/perl Build install
> Warning: You do not have permissions to install into 
> /usr/local/share/perl/5.8.\
> 0 at /usr/share/perl/5.8.0/ExtUtils/Install.pm line 114.
> mkdir /usr/local/share/perl/5.8.0/Data: Permission denied at 
> /usr/share/perl/5.\
> 8.0/ExtUtils/Install.pm line 176
> make: *** [install] Error 255
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : uname -a
> Linux perlmonk.org 2.4.18 #12 Fri Sep 13 17:49:41 EDT 2002 i686 GNU/Linux
> princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 :
> 

Is this a M::B issue or a security issue? I'm not that familiar with 
M::B's install code, so I honestly don't know what should happen here. I 
install software as root when on *nix so there is no problem. What does 
MakeMaker do? Can you install as root? Hopefully Ken will be back soon... ;)

Randy.

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

It works to build Pod::Coverage 0.12 on AIX, but the M::B XS test itself
fails.  It only fails two of ten tests, and those are related to
cleanup:

t/xs............ok 8/10Can't remove directory blib/arch/auto/XSTest: Do
not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib/arch/auto: Do not specify an existing file.
at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib/arch: Do not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
Can't remove directory blib: Do not specify an existing file. at
/home_dir/jfitzgi/work/Module-Build-0.21/blib/lib/Module/Build/Base.pm
line 1792
# Test 9 got: 'Couldn't remove 'blib': Do not specify an existing file.
' (t/xs.t at line 72)
#   Expected: ''
# Failed test 10 in t/xs.t at line 75
t/xs............FAILED tests 9-10
        Failed 2/10 tests, 80.00% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
------------------------------------------------------------------------
-------
t/xs.t                    10    2  20.00%  9-10
1 test skipped.
Failed 1/10 test scripts, 90.00% okay. 2/157 subtests failed, 98.73%
okay.

The test code is:

eval {$m->dispatch('realclean')};
ok $@, '';

# Make sure blib/ is gone after 'realclean'
ok not -e 'blib';

So, this may not be the fault of the patch but instead bad assumptions
on
the part of the test.  On the other hand, this same test passed with the
second revision of the patch (the current one being #3 I believe).

It may also be related to me running the test on an NFS mounted homedir.
I tried it on a local disk and it passed.  So, I'm willing to write off
the
failures to the assumptions of the test suite and say it's a good
candidate for
then next release unless someone has an OS/2 or VMS box to pound on it
with.

Thanks to everyone who helped.

-----Original Message-----
From: Randy W. Sims [mailto:Ra...@Th...]=20
Sent: Tuesday, November 18, 2003 8:09 PM
To: mod...@li...
Cc: James.FitzGibbon; Michael G Schwern
Subject: Re: [Module::Build] Problem building XS modules on AIX


On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
> I've updated Randy's patch to find the .exp files in the right place=20
> on AIX, but I don't have the necessary Windows environment to see if=20
> I've broken things there.

I've updated James' update of my patch ;) There were some Windows=20
problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if=20
you don't pass in something for some of the arguments even if its an=20
empty array or hash ref. I also changed it so that it generates the=20
def/exp file in the source directory and put the correct names into=20
add_to_cleanup().

James, can you please run this through the test suite one more time?

Michael, VMS wasn't calling Mksymlists before though it looks like it=20
should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to=20
now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is=20
this correct?

> Perhaps what is needed is to update EU::Mksymlists to both export the=20
> platform-specific extensions as constants and return the canonical=20
> path to the written file back to it's
> caller so that link_c() in M::B can act more intelligently.
>=20
> Thanks.

Seems like a harmless but beneficial change, since the name of the file=20
can vary depending on $^O, and there aught to be some way to find out=20
what it is without read the source.

Randy.

Re: [Module::Build] Problem building XS modules on AIX

[Michael G S. <sc...@po...>]

On Tue, Nov 18, 2003 at 09:08:38PM -0500, Randy W. Sims wrote:
> I've updated James' update of my patch ;) There were some Windows 
> problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 

This would not surprise me.


> Michael, VMS wasn't calling Mksymlists before though it looks like it 
> should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to 
> now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is 
> this correct?

Hell if I know.  I don't understand it at all.  Ask Charles Bailey.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
They had applied the blinders of steam-grilled hamburgers to my eyes.

Re: [Module::Build] Problem building XS modules on AIX

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

On 11/18/2003 10:36 AM, James.FitzGibbon wrote:
> I've updated Randy's patch to find the .exp files in the right place on
> AIX, but I
> don't have the necessary Windows environment to see if I've broken
> things there.

I've updated James' update of my patch ;) There were some Windows 
problems. I think ExtUtils::Mksymlists is buggy on Windows; it dies if 
you don't pass in something for some of the arguments even if its an 
empty array or hash ref. I also changed it so that it generates the 
def/exp file in the source directory and put the correct names into 
add_to_cleanup().

James, can you please run this through the test suite one more time?

Michael, VMS wasn't calling Mksymlists before though it looks like it 
should have. Looking at EU::Mksymlists lines 53-58, I changed M::B to 
now invoke Mksymlists if grep $^O, qw(aix MacOS MSWin32 os2 VMS). Is 
this correct?

> Perhaps what is needed is to update EU::Mksymlists to both export the
> platform-specific
> extensions as constants and return the canonical path to the written
> file back to it's
> caller so that link_c() in M::B can act more intelligently.
> 
> Thanks.

Seems like a harmless but beneficial change, since the name of the file 
can vary depending on $^O, and there aught to be some way to find out 
what it is without read the source.

Randy.