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

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

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

On Mon, Mar 27, 2006 at 04:07:24PM +0100, Nick Ing-Simmons wrote:
> Johan Vromans <jvr...@sq...> writes:
> >The following sequence of statements (copied from Config::IniFiles
> >2.38) confuses the version number detection:
> >
> >    package Config::IniFiles;
> >    $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
> >    require 5.004;
> >    use strict;
> >    # Eliminate annoying warnings
> >    if ($^W) {
> >        $Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
> >    }
> >
> >This causes the following message:
> >
> >    Package 'Config::IniFiles' already declared with version '2.38'
> >    ignoring new version ''.
> 
> The "creative use" being the assigning it to itself rather 
> than using 'our' or 'use vars' to mark it as not subject to 
> 'used only once' warning?
> 
> Would writing if on one line: 
> 
>      if ($^W) { $Config::IniFiles::VERSION = $Config::IniFiles::VERSION; }
> 
> Suffice to hide it from the pseudo-parser?

If the goal is to get Config::IniFiles to work with M::B rather than the
other way around, best just to make it:

  $Config::IniFiles::VERSION = $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];

in the first place.

Re: [Module::Build] Data::Package::*, File::ShareDir and the 'auto/' subdir

[Randy W. S. <ml...@th...>]

Steffen Schwigon wrote:
> Hi!
> 
> Once upon a time, I already asked a similar question, where to install
> non-perl files. I then solved it by installing files with an own
> suffix into @INC near the module.
> 
> This time I want to install rather large amounts of data.
> 
> I could install them again beside the module, but in the mean time I
> read about a "more official" sounding way in the documentation of the
> modules
> 
>   Data::Package (::SQLite)
>   File::ShareDir
>   Module::Install::Share
> 
> which would all solve this problem by installing data in the 'data/'
> subdir near the module and finding them there at runtime.
> 
> By looking into the source, it seems, Module::Install:Share simply
> uses a MakeMaker variable INST_AUTODIR (which itself is just a
> relative subdir to INST_LIBDIR).
> 
> I want to use this way (i.e., Data::Package::SQLite with data files in
> 'auto/'), but install them with Module::Build.
> 
> ==> The question:
> 
>     How can I detect the 'auto/' subdir at install time and define
>     rules in Build.PL that install, for instance, all files from a
>     'share/' subdir into the corresponding 'auto/' subdir?

I'm not sure M::B should support this directly. It's not an official 
place to store data AFAICT, despite the documentation. The 'auto' 
directory lives in the *architecture-dependent* directory. This is where 
dynamic libs, auto-split files, .packlist files, etc go.

Data files should be stored either next to the perl module file (or 
where the perl module would go if it's XS only) or they should be 
installed into '/usr/share/<dist-name>', '/usr/local/share/<dist-name>', 
'C:\Program Files\<dist-name> or whatever is relevant for the chosen 
platform. (Still hoping that one day there will be a Probe::Locations 
that will give pointers to those locations, possibly using terminology 
of the FHS to query them.)

I'm not saying we shouldn't provide accessors for the various install 
locations related to perl modules, etc., but it does not seem 
appropriate for your intended usage.

If this is a standard that I'm not aware of, please do let me know.

We do provide enough flexibility for you to set locations explicitly in 
your Build.PL or subclass, so you can use File::ShareDir to set them. 
See Module::Build::Cookbook, or feel free to ask here for some more 
examples or how-to.

Regards,
Randy.

Re: [Module::Build] SF.net is not long for this M::B world

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> So finally I get some time to look at a few M::B issues, and CVS seems 
> to be down.  I see this note on the sourceforge status page:
> 
>  ( 2006-03-23 10:28:40 - Project CVS Service )   2006-03-23: Starting at 
> 19:00 PST, CVS services will be unavailable for approximately 8 hours as 
> part of routine maintenance. We apologise for the inconvenience.
> 
> Of course, up above on the same page, CVS status is listed as "Online".
> 
> I'm tired of both CVS itself and these outages, so other than just 
> complaining publicly, I'm announcing that we'll switch to subversion 
> once we generate the 0.28 release, and perhaps try to move to the 
> svn.perl.org server too.  I don't know if it's more reliable or not, but 
> for some reason I'm sure it would be less frustrating.

I'm not overly fond of sf either. Most of my complaints have been about 
the mailing list which is where I run into the most problems by far. 
I've only ran into a few bumps with cvs, but I'm all for the change.

Is the mailing list going to be moved over to the perl.org server also? 
Will we be able to update gmane.org to the new list?

Where will the META.yml spec go?

Randy.

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> 
> On Mar 27, 2006, at 10:47 AM, Johan Vromans wrote:
> 
>>
>> Probably the best pseudo-solution to this pseudo-parsing problem is to
>> stop parsing after the first successful assignment, and put a remark
>> in the documentation.
> 
> I believe that's what we actually do now, in the latest beta versions.

It is except for one location when a fully-qualified package name is 
used: $Foo::Bar::VERSION vs $VERSION

I can fix that, or I can allow successive expressions involving the same 
VERSION. I already put together a patch for it. It would allow arbitrary 
expressions like

$VERSION = '1.01';
$VERSION = $VERSION + 1;
$VERSION += 2;

-

package Foo::Bar;
$VERSION = '1.01';

package Foo;
$VERSION = $Foo::Bar::VERSION;

The last one is a side effect, and incomplete in that order matters. 
Even that could be fixed by delaying evaluation until the file is 
completely scanned.

But how far to go?

The warning in the original post was meant to catch problems like

package Foo;
$VERSION = '1.23';
package Blah;
[...]
package Foo;
$VERSION = '2.34'; # re-opened package with differing version.

(This was from a problem Andreas reported a few months back with POE 
that turned out to be an unintentional buglet in POE.)

We can make such warnings optional, I guess.

What I really need is to scan CPAN for other problems like this. See 
what each alternative produces.

The patch I mentioned is attached for reference. It simplifies the main 
parsing routine a good bit, and add a good bit more flexibility. There 
is are two failures that exercise the bug mentioned above that I've 
intentionally left unresolved; in the original tests I had left a 
comment questioning whether the behavior was correct or not-it could be 
argued either way.

[This message is intentionally rambling, with no point.]

> It's worth noting, however, that we can fix M::B's parsing all we want, 
> and still there will be parsers on PAUSE and in MakeMaker that will barf 
> on the same input.  So probably it would be helpful for someone (not 
> me!) to have a tool that authors could run when they build their 
> distributions, looking for typical constructions that tend to cause such 
> barfs.

Module::Build::ModuleInfo can be used directly for this. It is 
completely stand-alone. At some point it could hopefully be merged with 
Module::Info.

Randy.

[Module::Build] Fwd: Module::Build integration with revision control and other goodies I need

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

[Nadim agreed that I could forward this message to the list, where  
he's now subscribed, so he could get better discussion. -Ken]

Begin forwarded message:
From: Nadim Khemir <na...@kh...>
Date: March 26, 2006 4:33:57 PM CST
To: ke...@ma...
Subject: Module::Build integration with revision control and other  
goodies I need

Hi, remember me and PBS (my module)? We are still using M::B though  
it was
very tough not to go back to a normal Makefile.PL when we started
distributing the module on windows platform. I had a lot of small  
problems,
things that build in cpan other in cpanp and still other with ppm.  
Add to
that some modules that you have to build by hand and you get a real
nightmare. I have added a Makefile.PL using Module::Build::Compat and it
seems to work fine but the 'create_makefile_pl' doesn't. I have  
certainly
done something wrong :)

I'm trying to use M::B more intelligently and I've even read the doc  
twice
(which is what I do every time all goes wrong).Here is what I'm  
trying to put
together this time.

- have a more interactive install. I haven't started yet but I think  
this will
be needed soon. A few examples or links to some modules using this  
would be
great

- I used to have a full cpan miror but I now use CPAN::Mini so I am  
planning
to update my repository directly with CPAN::Mini::Inject and only  
build with
the 'cpan' command. No more ./Build install. or install should call  
'cpan'.

- I'm using svk so I want to be able to create distribution that  
contain the
revision number "0.41.182" everytime I build a distribution (that is
everytime since I need a distribution to inject in CPAN mini so I can  
install
from 'cpan'). Getting the revison and generating the tar.gz is  
trivial when I
am in my project directory but it doesn't work when I install.

# running Build.PL
/usr/bin/perl5.8.8 Build.PL
Creating custom builder _build/lib/PBS/Builder.pm in _build/lib/PBS
path /home/nadim/.cpan/build/PerlBuildSystem-0.41.182 is not a  
checkout path.
Died at Build.PL line 158.
Couldn't run Build.PL:
at /usr/lib/perl5/vendor_perl/5.8.7/Module/Build/Compat.pm line 172.
...

I can think about one solution. when I run 'dist', I make sure svk is  
there
and I create a file that I add to the distribution. At install time,  
I try
with svk and if it fails, I'll fall back on the generated file. This  
is a bit
contrieved. Is there another way to do that?

A Module::Build::SVK would be nice to have.

I'm working on a Module::Build::Inject idea butI'm not sure it's a  
good idea.

Cheers, Nadim.

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

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

On Mar 27, 2006, at 10:47 AM, Johan Vromans wrote:

>
> Probably the best pseudo-solution to this pseudo-parsing problem is to
> stop parsing after the first successful assignment, and put a remark
> in the documentation.

I believe that's what we actually do now, in the latest beta versions.

It's worth noting, however, that we can fix M::B's parsing all we  
want, and still there will be parsers on PAUSE and in MakeMaker that  
will barf on the same input.  So probably it would be helpful for  
someone (not me!) to have a tool that authors could run when they  
build their distributions, looking for typical constructions that  
tend to cause such barfs.

  -Ken

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

[Johan V. <jvr...@sq...>]

John Peacock <jpe...@ro...> writes:

> If that second section was reformatted to:
> ...
> it wouldn't match the regex and hence not issue the warning.

(Also responding to Nick's reply)

BIG DISCLAIMER: Don't shoot me, I'm only the messenger.
BIG DISCLAIMER: I'm not blaming M::B, the problem is much more
                fundamental. 

Fact of the matter is that Perl uses the value of $VERSION as it is
upon completion of the load, which implies that any method using
static parsing may lead to surprises.

    package Foo;

    $VERSION = 1;

    $VERSION++;

    if ( -s "/etc/passwd" == 2011 ) {
        $VERSION *=2;
    }

    1;

This indeed is version 2 or 4, depending on your /etc/passwd. 

Probably the best pseudo-solution to this pseudo-parsing problem is to
stop parsing after the first successful assignment, and put a remark
in the documentation.

-- Johan

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

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

Johan Vromans <jvr...@sq...> writes:
>The following sequence of statements (copied from Config::IniFiles
>2.38) confuses the version number detection:
>
>    package Config::IniFiles;
>    $Config::IniFiles::VERSION =3D (qw($Revision: 2.38 $))[1];
>    require 5.004;
>    use strict;
>    # Eliminate annoying warnings
>    if ($^W) {
>        $Config::IniFiles::VERSION =3D $Config::IniFiles::VERSION;
>    }
>
>This causes the following message:
>
>    Package 'Config::IniFiles' already declared with version '2.38'
>    ignoring new version ''.

The "creative use" being the assigning it to itself rather=20
than using 'our' or 'use vars' to mark it as not subject to=20
'used only once' warning?

Would writing if on one line:=20

     if ($^W) { $Config::IniFiles::VERSION =3D $Config::IniFiles::VERSION; }

Suffice to hide it from the pseudo-parser?




>
>-- Johan
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webca=
st
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
>_______________________________________________
>Module-build-general mailing list
>Mod...@li...
>https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

[John P. <jpe...@ro...>]

Johan Vromans wrote:
> The following sequence of statements (copied from Config::IniFiles
> 2.38) confuses the version number detection:
> 
>     package Config::IniFiles;
>     $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
>     require 5.004;
>     use strict;
>     # Eliminate annoying warnings
>     if ($^W) {
>         $Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
>     }
> 
> This causes the following message:
> 
>     Package 'Config::IniFiles' already declared with version '2.38'
>     ignoring new version ''.

If that second section was reformatted to:

     if ($^W) {
         $Config::IniFiles::VERSION =
		$Config::IniFiles::VERSION;
     }

it wouldn't match the regex and hence not issue the warning.  You should 
let the author know...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

[Module::Build] Buglet: Creative use of $VERSION confuses M::B

[Johan V. <jvr...@sq...>]

The following sequence of statements (copied from Config::IniFiles
2.38) confuses the version number detection:

    package Config::IniFiles;
    $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
    require 5.004;
    use strict;
    # Eliminate annoying warnings
    if ($^W) {
        $Config::IniFiles::VERSION = $Config::IniFiles::VERSION;
    }

This causes the following message:

    Package 'Config::IniFiles' already declared with version '2.38'
    ignoring new version ''.

-- Johan

Re: [Module::Build] M::B and no_index

[Johan V. <jvr...@sq...>]

"Randy W. Sims" <ml...@th...> writes:

> the build script should work fine without those changes. I just
> remembered that we store the @INC and hard code it into the 'Build'
> script.

> use lib 'inc';
> use Module::Build;
>
> ...
>
> $builder->create_build_script();

1. Almost. For example, I use "use lib '.'" to get '.' as the first
   location to try. In the default perl @INC, '.' is the last entry.
   But since '.' occurs in the default @INC, it will not be written to
   the Build script, and the effect of "use lib '.'" is lost.

   Now, I cannot imagine people deliberately mixing up @INC, but
   putting '.' in front seems not uncommon to me. Why not change the
   "push @INC ..." code to "@INC = ( ... )" and supply the exact
   actual inc path?

2. This is also the easiest solution for me: move the addtional
   modules to inc and all is fine. No other changes necessary.

Thanks for the good work!

-- Johan

Re: [Module::Build] M::B and no_index

[David G. <da...@hy...>]

Randy W. Sims wrote:
> In the Module::Build directory, run
> 
>   perl Build.PL
>   ./Build
> 
> Then copy 'blib/lib' to your distro:
> 
>   cp -r blib/lib/* ~/Foo/inc/

And don't forget to add inc/ to your META.yml 'no_index' list.

David

Re: [Module::Build] M::B and no_index

[Randy W. S. <ml...@th...>]

Randy W. Sims wrote:
> Johan Vromans wrote:
>> Johan Vromans <jvr...@sq...> writes:
>>
>>> Okay, now I've found it I'll give it a try.
>>
>> This version seems to cure a lot of problems. Nice.
>>
>> However, for the time being, I think it's better to distribute this
>> version of M::B together with the application. While it is trivial to
>> add a "use lib '.';" to the Build.PL, how can I achieve this with the
>> generated Build script?
> 
> In the Module::Build directory, run
> 
>   perl Build.PL
>   ./Build
> 
> Then copy 'blib/lib' to your distro:
> 
>   cp -r blib/lib/* ~/Foo/inc/
> 
> Then write your Build.PL something like:

Actually, the build script should work fine without those changes. I 
just remembered that we store the @INC and hard code it into the 'Build' 
script. So, after coping as above, this 'Build.PL' should work fine:

use strict;
use warnings;

use lib 'inc';
use Module::Build;

my $builder = Module::Build->new(
     module_name => 'Foo',
     license     => 'perl',
);

$builder->create_build_script();

__END__

Re: [Module::Build] M::B and no_index

[Randy W. S. <ml...@th...>]

Johan Vromans wrote:
> Johan Vromans <jvr...@sq...> writes:
> 
>> Okay, now I've found it I'll give it a try.
> 
> This version seems to cure a lot of problems. Nice.
> 
> However, for the time being, I think it's better to distribute this
> version of M::B together with the application. While it is trivial to
> add a "use lib '.';" to the Build.PL, how can I achieve this with the
> generated Build script?

In the Module::Build directory, run

   perl Build.PL
   ./Build

Then copy 'blib/lib' to your distro:

   cp -r blib/lib/* ~/Foo/inc/

Then write your Build.PL something like:

use strict;
use warnings;

use lib 'inc';
use Module::Build;

use Cwd;
my $cwd = cwd();

my $build_class = Module::Build->subclass(code => <<"---");
use File::Spec;
my \$inc = File::Spec->catdir("$cwd", 'inc');
unshift(\@INC, \$inc);
use Module::Build;

sub ACTION_version {
   print qq(Using Module::Build version \$Module::Build::VERSION\n);
}
---

my $builder = $build_class->new(
     module_name         => 'Foo',
     license             => 'perl',
);

$builder->create_build_script();

__END__


Regards,
Randy.

Re: [Module::Build] M::B and no_index

[Johan V. <jvr...@sq...>]

Johan Vromans <jvr...@sq...> writes:

> Okay, now I've found it I'll give it a try.

This version seems to cure a lot of problems. Nice.

However, for the time being, I think it's better to distribute this
version of M::B together with the application. While it is trivial to
add a "use lib '.';" to the Build.PL, how can I achieve this with the
generated Build script?

-- Johan

Re: [Module::Build] SF.net is not long for this M::B world

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

On Mar 23, 2006, at 10:32 PM, Stephen Adkins wrote:

> Ken,
>
> Can you give us a target timeframe for when 0.28 might go out?
> Is there a feature freeze period before that?
>
> I have some things I might hope to have considered before
> the next major release.

Hi Stephen,

The feature freeze has already happened - as soon as we get bleadperl  
working with no errors and no enormous warnings on the major  
platform, we'll call it 0.28 .

  -Ken

Re: [Module::Build] M::B and no_index

[John P. <jpe...@ro...>]

Johan Vromans wrote:
> I use a CPAN mirror. Interesting is that 0.27_01 through 0.27_09 are
> in authors/id/KWILLIAMS, but not in modules/by-module/ (apparently
> since it's beta).

Yeah, that's how CPAN works.  The only stuff in modules/by-module/ (and 
hence the indexes) is the official releases (non-alpha).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] M::B and no_index

[Johan V. <jvr...@sq...>]

John Peacock <jpe...@ro...> writes:

> Johan Vromans wrote:
>> David Golden <da...@hy...> writes:
>>> Are you unable to upgrade M::B to the 0.27 beta?
>> Maybe, if I would be able to find it. It's not on CPAN.
>
> That's funny, I see 0.27_01 through 0.27_09 on this page:
>
> 	http://search.cpan.org/~kwilliams/Module-Build-0.2612/
>
> under "Latest Dev. Release" and "Other Releases."  How are you trying
> to install (CPAN or CPANPLUS)?

I use a CPAN mirror. Interesting is that 0.27_01 through 0.27_09 are
in authors/id/KWILLIAMS, but not in modules/by-module/ (apparently
since it's beta). Okay, now I've found it I'll give it a try.

Thanks.

-- Johan

Re: [Module::Build] M::B and no_index

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

On Mar 24, 2006, at 08:54, Johan Vromans wrote:

> SourceForge only has 0.2611 and a 0.27_01 which seems to be older than
> 0.2611. CPAN has 0.2612.
> The SourceForge home page for M::B only lists META-spec files...
> Confusing, at least.

There's always CVS. That's where I get it.

   http://sourceforge.net/cvs/?group_id=45731

Best,

David

Re: [Module::Build] M::B and no_index

[John P. <jpe...@ro...>]

Johan Vromans wrote:
> David Golden <da...@hy...> writes:
>> Are you unable to upgrade M::B to the 0.27 beta?
> 
> Maybe, if I would be able to find it. It's not on CPAN.

That's funny, I see 0.27_01 through 0.27_09 on this page:

	http://search.cpan.org/~kwilliams/Module-Build-0.2612/

under "Latest Dev. Release" and "Other Releases."  How are you trying to 
install (CPAN or CPANPLUS)?

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] M::B and no_index

[Johan V. <jvr...@sq...>]

David Golden <da...@hy...> writes:

> [...] it still "works" for users with 0.2612 as it's not used at
> install time.

The first thing that M::B does when using "Build dist" is removing an
existing META.yaml...

> Are you unable to upgrade M::B to the 0.27 beta?

Maybe, if I would be able to find it. It's not on CPAN.

SourceForge only has 0.2611 and a 0.27_01 which seems to be older than
0.2611. CPAN has 0.2612.
The SourceForge home page for M::B only lists META-spec files...
Confusing, at least.

-- Johan

Re: [Module::Build] M::B and no_index

[David G. <da...@hy...>]

Johan Vromans wrote:
> Does M::B (0.2612) support the no_index property and if so, how can I
> use it?

On 0.27+, I've used this as an argument in Build.PL:

     meta_add            => {
         no_index            => { dir => [ qw/examples/ ] }
     },

I don't think there is an equivalent on 0.2612.  However, if you 
generate your META.yml with 0.27, it still "works" for users with 0.2612 
as it's not used at install time.  I.e. I use 0.27 but with 0.26 
compatible build, test and install features.  I use 0.27 specific 
features only for distribution creation.

Are you unable to upgrade M::B to the 0.27 beta?

Regards,
David Golden

[Module::Build] M::B and no_index

[Johan V. <jvr...@sq...>]

Does M::B (0.2612) support the no_index property and if so, how can I
use it?

-- Johan

Re: [Module::Build] Cannot forceunlink C:\Perl\site\lib\auto\Compress\Zlib\Zlib.dll: Permission denied at C:/Perl/lib/File/Find.pm line 906

[demerphq <dem...@gm...>]

On 3/23/06, Ron Savage <ro...@sa...> wrote:
> Hi Folks
>
> I've been investigating this problem.
>
> I get such an error with Compress::Zlib, Params::Validate and Time::HiRes=
.
>
> Here's what I've found, under Win2K:
>
> o If Apache+mod_perl is not installed (i.e. as a Windows service), I do n=
ot get
> this error.
>
> o If Apache+mod_perl is installed but the service is not started, I do no=
t get
> this error
>
> o If the service is started, I get this error
>
> What complicates the issue is that Apache, or perhaps Windows, is inconsi=
stent
> about whether or not it is installed. Here's a log of a few attempts to p=
lay
> with this:

This is a well known set of issues. You cant delete files that are
open on win32. In some cases you can rename them, but in others you
cant do anything but schedule the removal of the file at boot time.
Normally when a .dll is opened it is opened such that it can be
renamed away, however if the .dll is being used in more complicated
ways then it may not be renamable untill all processes using it have
terminated.  Thus when the service is running the .dlls are open and
they cant be deleted.

There is an existing workaround. If you do

cpan> install YVES/ex-ExtUtils-Install-1.3702.tar.gz

The youll have an updated version of ExtUtils::Install that knows how
to do the rename trick, and/or use Win32API::File to handle these
issues at boottime. (Such as removing the renamed files, or installing
files that are locked at the time of install.)

I would very much appreciate feedback as to how well using this bundle
resolves the listed problems. Not that you _cannot_ install it by
module name, you must use the fully qualified distro name.

BTW, its been a subject of discussion for some time to make this the
official distro for EU-Install. However we are still waiting on
Michael Schwern to give me permissions on the module in CPAN/PAUSE.

Cheers,
Yves



--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] SF.net is not long for this M::B world

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

On Mar 23, 2006, at 20:26, Ken Williams wrote:

> I'm tired of both CVS itself and these outages, so other than just  
> complaining publicly, I'm announcing that we'll switch to  
> subversion once we generate the 0.28 release, and perhaps try to  
> move to the svn.perl.org server too.  I don't know if it's more  
> reliable or not, but for some reason I'm sure it would be less  
> frustrating.

I moved Bricolage from SF CVS to svn.perl.org a couple of years ago,  
and have been nothing but happy with the move. I say go for it!  
Robert Spier is the man to ask.

Best,

David