module-build-general Mailing List for Module::Build (Page 164)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve P. <sp...@ep...> - 2003-07-14 20:06:39
|
Hi list, I'm a Module::Build newbie - I've been playing with it the past couple of days and see a lot of potential with the project. Kudos to Ken for starting it up! I've got a wee bit of experience with MakeMaker's manifypods target, and seeing as the manifypods Action isn't implemented yet and it's something I need before I can switch over, I decided to have a go at it. Hope I'm not stepping on anyone's toes... I got as far as generating MAN3 pods - no installation or MAN1 pods yet, but it's getting late and I thought now might be a good time to stop and get some feedback. So I've attached a patch, comments are welcome. Will prolly finish it off later this week if people like the look of it.. Regards, -Steve |
|
From: Ken W. <ke...@ma...> - 2003-07-10 16:25:40
|
On Thursday, July 10, 2003, at 09:30 AM, Mathieu Arnold wrote: > +-le 10/07/2003 09:10 -0500, Ken Williams =E9crivait : > | > | On the command line, that would look like this: > | > | perl Build.PL install_path=3Dlib=3D/foo/lib=20 > install_path=3Darch=3D/foo/lib/arch > > it does not work. Ah yes, you're right. Oops. I've got a fix for this written, I'll add=20= some tests too and get the fix uploaded. -Ken |
|
From: Mathieu A. <ma...@ma...> - 2003-07-10 14:30:31
|
+-le 10/07/2003 09:10 -0500, Ken Williams =E9crivait :
|=20
| On Thursday, July 10, 2003, at 07:09 AM, Mathieu Arnold wrote:
|=20
|> I've tried about all possible combinaisons between
|> perl Build.PL install_base=3D/my/test/path
|> to
|> perl Build.PL config=3Dinstall_path=3D/my/test/path
|> going through
|> perl Build.PL install_path=3Dinstall_path=3D/my/test/path (putting it =
once=20
|> does
|> not work)
|> or
|> perl Build.PL install_path=3Dinstall_base=3D/my/test/path
|=20
| Hi Mathieu,
|=20
| There are docs about it in the "How Installation Paths are Determined"
| section:
|=20
| ----------------------------------------------------------------------
| =3Dhead3 install_path
|=20
| Once the defaults have been set, you can override them. You can set
| individual entries by using the C<install_path> parameter:
|=20
| my $m =3D Module::Build->new
| (...other options...,
| install_path =3D> {lib =3D> '/foo/lib',
| arch =3D> '/foo/lib/arch'});
|=20
| On the command line, that would look like this:
|=20
| perl Build.PL install_path=3Dlib=3D/foo/lib =
install_path=3Darch=3D/foo/lib/arch
it does not work.
| or this:
|=20
| Build install install_path=3Dlib=3D/foo/lib =
install_path=3Darch=3D/foo/lib/arch
That does work.
If the former could work, it would be really great :)
It would be less painful.
| ----------------------------------------------------------------------
|=20
| BTW, the 'destdir' parameter isn't doing what you need?
Well, if I set destdir=3D/tmp/a, it will install files into
/tmp/a/usr/local/lib/site_perl/PERL_VER/
What I need is /tmp/a/lib/site_perl/PERL_VER/ which is what PREFIX does
with MakeMaker :)
>From what I can read in M::B doc, you don't seem to like PREFIX :)
But FreeBSD uses it a lot and it would really be great to have the
possibility to have the same kind of functionnality :)
--=20
Mathieu Arnold
|
|
From: Ken W. <ke...@ma...> - 2003-07-10 14:10:55
|
On Thursday, July 10, 2003, at 07:09 AM, Mathieu Arnold wrote:
> I've tried about all possible combinaisons between
> perl Build.PL install_base=/my/test/path
> to
> perl Build.PL config=install_path=/my/test/path
> going through
> perl Build.PL install_path=install_path=/my/test/path (putting it once
> does
> not work)
> or
> perl Build.PL install_path=install_base=/my/test/path
Hi Mathieu,
There are docs about it in the "How Installation Paths are Determined"
section:
----------------------------------------------------------------------
=head3 install_path
Once the defaults have been set, you can override them. You can set
individual entries by using the C<install_path> parameter:
my $m = Module::Build->new
(...other options...,
install_path => {lib => '/foo/lib',
arch => '/foo/lib/arch'});
On the command line, that would look like this:
perl Build.PL install_path=lib=/foo/lib install_path=arch=/foo/lib/arch
or this:
Build install install_path=lib=/foo/lib install_path=arch=/foo/lib/arch
----------------------------------------------------------------------
BTW, the 'destdir' parameter isn't doing what you need?
-Ken
|
|
From: Mathieu A. <ma...@ma...> - 2003-07-10 12:10:09
|
+-le 09/07/2003 22:53 -0500, Ken Williams =E9crivait : | Hi, |=20 | - Added support for the 'install_path' parameter, which allows custom | specification of where things should be installed. This is a major | improvement to Module::Build's functionality. |=20 | - Added the 'install_base' parameter. Provides an easy way to | install to local or alternative directory trees. How is this supposed to work ? I've tried about all possible combinaisons between=20 perl Build.PL install_base=3D/my/test/path to perl Build.PL config=3Dinstall_path=3D/my/test/path going through perl Build.PL install_path=3Dinstall_path=3D/my/test/path (putting it once = does not work) or=20 perl Build.PL install_path=3Dinstall_base=3D/my/test/path=20 but no one seems to be of any interest to Build.PL (and to Build either when perl Build install ....) So, I'm wondering... *How* is it supposed to work :) --=20 Mathieu Arnold |
|
From: Ken W. <ke...@ma...> - 2003-07-10 03:53:50
|
Hi,
The uploaded file
Module-Build-0.19.tar.gz
has entered CPAN as
file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.19.tar.gz
size: 74015 bytes
md5: c1647888d63033446583f9697fb7b426
Oodles and oodles of changes since 0.18:
- Added support for the 'install_path' parameter, which allows custom
specification of where things should be installed. This is a major
improvement to Module::Build's functionality.
- Added the 'install_base' parameter. Provides an easy way to
install to local or alternative directory trees.
- We now install scripts by default to $Config{installsitebin}
instead of $Config{installscript}. Neither is a great choice, but
the former is likely to be [analogous to] /usr/local/bin, and the
latter is likely to be [something like] /usr/bin . If/when there's
a $Config{installsitescript}, we'll start using that automatically.
- Fixed a problem on Win32 in which C and XS files wouldn't be
compiled properly, and the user would see an error about 'Can't
locate object method "format_compiler_cmd"'.
(http://rt.cpan.org/Ticket/Display.html?id=2391)
- We now use the correct perl interpreter (via
Module::Build->find_perl_interpreter) in pass-through makefiles.
- The t/compat.t test now uses $Config{make} instead of just 'make'
to test makefile compatibility. This fixes some failures on Win32.
We also skip this test entirely if no make utility is available.
- Alternative distribution layouts are now supported via the
'pm_files', 'pod_files', 'xs_files', 'PL_files', and 'script_files'
parameters to new(). This should help people transition from
MakeMaker, and might even help us write an automatic transition
tool.
- Added tests to t/runthrough.t that check to see installation is
happening correctly.
- Added experimental code to build a .ppd file, in support of
ActiveState's "Perl Package Manager". [original patch by Dave
Rolsky]
- For authors who use Module::Signature to sign their distributions,
we now create the SIGNATURE file right in the distribution
directory, rather than creating it in the top-level directory and
copying it into place. This solves problems related to having
files get out of date with respect to their signatures.
- We now don't depend on Module::Info to scan for packages during the
'dist' action anymore, because it's way too aggressive about
loading other modules that you may not want loaded. We now just
(ick, yuck) scan the .pm files with a regular expression to find
"package Foo::Bar;" statements.
- Silenced some annoying copyright/logo output from Microsoft 'nmake'
during Makefile compatibility testing. [Randy W. Sims]
- Command-line arguments may now either be specified using the syntax
'--foo foovalue' as well as the traditional syntax 'foo=foovalue'.
The former is often more convenient for shell tab-completion when
the value is a filename (as in 'Build test --test_files t/basic.t').
- Command-line arguments may now include non-named parameters, which
make some actions more natural. For instance, the 'diff' action
may now be invoked as 'Build diff -u' rather than as
'Build diff flags=-u'.
- Pass-through Makefile.PLs now convert unknown Makefile.PL
parameters to lower-case and hand them to Build.PL, rather than
ignoring them. This means we only have to account for the
differences in the interface, not the entire interface, in
translating parameters.
- We now issue a warning & don't proceed if asked to make a distdir
and there's no MANIFEST or it's empty.
- Moved INSTALL to INSTALL.txt to increase compatibility with various
odd versions of 'make' during 'make install' on case-insensitive
filesystems (like nmake on Win32, often). Only affects the
Makefile compatibility layer. [reported by Andrew Savige]
- Module::Build->known_actions() now works as a class method.
- Pass-through makefiles now list each action individually rather
than using a ".DEFAULT" catch-all. This improves compatibility
with 'nmake' on Win32, and probably some other less common 'make'
dialects. [Andrew Savige]
- We're now more aggressive about testing the pass-through makefiles,
e.g. making sure they can run 'all' and 'test' targets, and making
sure the Makefile itself actually exists.
- Fixed a problem with check_installed_status() when installed
version contains non-numeric characters like underscores.
- Fixed a problem with a bareword 'File::Spec' in one of the test
scripts that caused it not to compile under 5.8.0 (but is fine
under 5.6).
- Fixed a problem with the 'destdir' installation parameter on
platforms that have volume identifiers in path names (like "C:" on
Win32). The identifier is now stripped from installation
directories before prepending the destdir path. The destdir path
may still have a volume identifier on it.
- Added an 'add_to_cleanup' parameter to new() that calls
add_to_cleanup() immediately for the given files.
- The distribution directory (e.g. Sample-Module-0.13/ ) will now be
deleted during the 'clean' or 'realclean' actions.
- During testing of modules, blib/lib and blib/arch are now added as
absolute paths, not relative. This helps tests that load the
modules at runtime and may change the current working directory
(like Module::Build itself does during testing).
- The $Config{cc} entry on some people's systems is something like
'ccache gcc', so we now split that string using split_like_shell().
[Richard Clamp]
- Added documentation for 'extra_linker_flags' parameter, and added a
corresponding 'extra_compiler_flags' parameter. [original patch by
Richard Clamp]
- The pass-through Makefile created by Module::Build::Compat now
supports MakeMaker options like POLLUTE=1 and INC. We also just
warn & skip when we see any unknown MM parameters, rather than
dying. [Dave Rolsky]
- Fixed an error about how @INC and $ENV{PERL5LIB} interact during
the testing of M::B itself. [jk <bil...@fa...>]
- The pass-through Makefile doesn't include 'recommended' M::B
dependencies in the Makefile anymore, since they're not strictly
necessary. In particular, this makes installing M::B itself
easier.
- A new 'create_makefile_pl' parameter lets you use
Module::Build::Compat during the 'distdir' (or 'dist') action to
automatically create a Makefile.PL for compatibility with
ExtUtils::MakeMaker. The parameter's value should be one of the
styles named in the Module::Build::Compat documentation.
- When compiling C code, we now respect 'pollute' and 'inc'
parameters. (XXX - needs docs) [Dave Rolsky]
- Made the creation of the "install map" more generic. (XXX - needs
documentation)
- Fixed a problem in which add_to_cleanup() didn't note cleanup files
unless create_build_script() had been called already. [Dave Rolsky]
- During 'Build dist', we no longer have to load each .pm file (via
Module::Info) to determine the $VERSION numbers inside. Instead,
we call our internal version_from_file() method, which is the same
thing MakeMaker and PAUSE and search.cpan.org do. Also fixes a
failure when Module::Info is installed in a nonstandard directory.
[reported by Teun Burgers]
- Fixed some failing test code on Windows - open files can't be
deleted. [Andrew Savige]
- The Cygwin platform is now treated as a flavor of Unix rather than
a flavor of Windows. [chocolateboy]
- We're now more aggressive about adding temporary C compilation
files (*.c, *.bs) to the cleanup list. [Dave Rolsky]
- When constructing the list in META.yml of packages provided by this
distribution, we now use the same rules as the PAUSE scanner does
when a single .pm file contains multiple VERSIONs. [Andreas Koenig]
- check_installed_status() now works as both a class method and an
object method (and is documented so). [Spotted by Dave Rolsky]
-Ken
|
|
From: Randy W. S. <Ra...@Th...> - 2003-07-09 23:58:41
|
On 7/9/2003 11:56 AM, Ken Williams wrote:
> Okay, I'll apply the patch below.
>
[patch snipped]
Your patch applied and ran successfully.
perl Build test
t/basic.........ok
t/compat........ok
t/install.......ok
t/runthrough....ok
t/signature.....
You need a passphrase to unlock the secret key for
user: "Randy W. Sims <Ra...@Th...>"
1024-bit DSA key, ID D8681C21, created 2003-02-27
==> SIGNATURE file created successfully. <==
t/signature.....ok
t/xs............ok
All tests successful.
Files=6, Tests=87, 88 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Thanks,
Randy.
--
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
|
|
From: Ken W. <ke...@ma...> - 2003-07-09 15:56:20
|
On Tuesday, July 8, 2003, at 09:07 PM, Randy W. Sims wrote:
>
> All clear...
Great, thanks for testing it.
> BTW, the annoying output from make can be eleminated with the
> '-nologo' switch to nmake (if $Config{make} eq 'nmake').
Okay, I'll apply the patch below.
-Ken
==========================================================
--- t/compat.t 10 Jun 2003 15:43:41 -0000 1.4
+++ t/compat.t 9 Jul 2003 15:53:51 -0000
@@ -10,6 +10,7 @@
plan tests => 23;
ok(1); # Loaded
+my @make = $Config{make} eq 'nmake' ? ('nmake', '-nologo') :
($Config{make});
my $goto = File::Spec->catdir( Module::Build->cwd, 't', 'Sample' );
chdir $goto or die "can't chdir to $goto: $!";
@@ -29,17 +30,17 @@
ok $result;
ok -e 'Makefile', 1, "Makefile exists";
- ok $build->do_system($Config{make});
+ ok $build->do_system(@make);
# Can't let 'test' STDOUT go to our STDOUT, or it'll confuse
Test::Harness.
my $success;
my $output = stdout_of( sub {
- $success = $build->do_system($Config{make},
'test');
+ $success = $build->do_system(@make, 'test');
} );
ok $success;
ok uc $output, qr{DONE\.|SUCCESS};
- ok $build->do_system($Config{make}, 'realclean');
+ ok $build->do_system(@make, 'realclean');
$build->dispatch('realclean');
ok not -e 'Makefile.PL';
}
==========================================================
|
|
From: Randy W. S. <Ra...@Th...> - 2003-07-09 02:08:04
|
On 7/7/2003 1:31 PM, Ken Williams wrote: > Hi Randy etc., > > I think I just fixed the following bug on Win32: > > http://rt.cpan.org/Ticket/Display.html?id=2391 > > I've also added a test to t/xs.t that attempts to catch this situation. > Could you (or someone else) try running the tests from the latest CVS > (assuming anonymous-CVS ever catches up - it should be revision 1.8 of > xs.t) on Win32 and see whether they work? > > Thanks. > > -Ken > All clear... [X:\home\Administrator\projects\Module-Build] $ set TEST_SIGNATURE=1 [X:\home\Administrator\projects\Module-Build] $ perl Build.PL Checking whether your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. Creating new 'Build' script for 'Module-Build' version '0.18_04' [X:\home\Administrator\projects\Module-Build] $ perl Build lib/Module/Build/Platform/darwin.pm -> blib\lib/Module/Build/Platform/darwin.pm lib/Module/Build/Base.pm -> blib\lib/Module/Build/Base.pm lib/Module/Build/Platform/VMS.pm -> blib\lib/Module/Build/Platform/VMS.pm lib/Module/Build/Platform/EBCDIC.pm -> blib\lib/Module/Build/Platform/EBCDIC.pm lib/Module/Build/Platform/Amiga.pm -> blib\lib/Module/Build/Platform/Amiga.pm lib/Module/Build/PPMMaker.pm -> blib\lib/Module/Build/PPMMaker.pm lib/Module/Build/Cookbook.pm -> blib\lib/Module/Build/Cookbook.pm lib/Module/Build/Platform/Windows.pm -> blib\lib/Module/Build/Platform/Windows.pm lib/Module/Build/Platform/MPEiX.pm -> blib\lib/Module/Build/Platform/MPEiX.pm lib/Module/Build/Platform/Unix.pm -> blib\lib/Module/Build/Platform/Unix.pm lib/Module/Build/Compat.pm -> blib\lib/Module/Build/Compat.pm lib/Module/Build/Platform/MacOS.pm -> blib\lib/Module/Build/Platform/MacOS.pm lib/Module/Build/Platform/VOS.pm -> blib\lib/Module/Build/Platform/VOS.pm lib/Module/Build/Platform/RiscOS.pm -> blib\lib/Module/Build/Platform/RiscOS.pm lib/Module/Build.pm -> blib\lib/Module/Build.pm lib/Module/Build/Platform/Default.pm -> blib\lib/Module/Build/Platform/Default.pm [X:\home\Administrator\projects\Module-Build] $ perl Build test t/basic.........ok t/compat........ok 4/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 5/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 7/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 11/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 12/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 14/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 18/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 19/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok 21/23 Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. t/compat........ok t/install.......ok t/runthrough....ok t/signature..... You need a passphrase to unlock the secret key for user: "Randy W. Sims <Ra...@Th...>" 1024-bit DSA key, ID D8681C21, created 2003-02-27 ==> SIGNATURE file created successfully. <== t/signature.....ok t/xs............ok All tests successful. Files=6, Tests=87, 79 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) BTW, the annoying output from make can be eleminated with the '-nologo' switch to nmake (if $Config{make} eq 'nmake'). Regards, Randy. |
|
From: Dave R. <au...@ur...> - 2003-07-07 22:17:25
|
On Mon, 7 Jul 2003, Ken Williams wrote: > So, now I'm checking the following patch into CVS. What do you think? > It at least doesn't have that *particular* problem anymore. :-/ It's not ideal, but much better than spewing lots of errors messages when a module author tries to build a distro for the first time. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-07 22:09:54
|
On Monday, July 7, 2003, at 04:36 PM, Ken Williams wrote:
>
> On Monday, July 7, 2003, at 02:30 PM, Dave Rolsky wrote:
>
>> Ok, I just found a somwhat serious bug in the 0.18_04 release, and I
>> think
>> it's still present in the CVS version.
>>
>> If I run "./Build dist" on a new distro, it tries to load all the .pm
>> files in the MANIFEST file and scan them for packages via
>> Module::Info.
>>
>> But if you've never installed the distro at hand, then loading the
>> various
>> module may fail unless the ./lib (or equivalent) directory is
>> included in
>> your lib path.
>>
>> I'm not sure if this is a new bug or if I've just not used
>> Module::Build
>> for an entirely new module, which is what provoked the problem.
>
> Argh, you're right. I wish Module::Info could override CORE::use() or
> something so it wouldn't have to run any other modules to get the > info.
So, now I'm checking the following patch into CVS. What do you think?
It at least doesn't have that *particular* problem anymore. :-/
-Ken
Index: Build.PL
===================================================================
RCS file: /cvsroot/module-build/Module-Build/Build.PL,v
retrieving revision 1.25
diff -u -r1.25 Build.PL
--- Build.PL 1 Jul 2003 23:33:27 -0000 1.25
+++ Build.PL 7 Jul 2003 22:08:37 -0000
@@ -31,7 +31,6 @@
'Archive::Tar' => '1.00',
'ExtUtils::Install' => 0.30,
'ExtUtils::ParseXS' => 2.02,
- 'Module::Info' => 0,
# Module::Signature => 0.21, # Our support isn't good enough yet
},
build_requires => {
Index: Changes
===================================================================
RCS file: /cvsroot/module-build/Module-Build/Changes,v
retrieving revision 1.105
diff -u -r1.105 Changes
--- Changes 7 Jul 2003 16:37:27 -0000 1.105
+++ Changes 7 Jul 2003 22:08:38 -0000
@@ -10,6 +10,12 @@
locate object method "format_compiler_cmd"'.
(http://rt.cpan.org/Ticket/Display.html?id=2391)
+ - We now don't depend on Module::Info to scan for packages during the
+ 'dist' action anymore, because it's way too aggressive about
+ loading other modules that you may not want loaded. We now just
+ (ick, yuck) scan the .pm files with a regular expression to find
+ "package Foo::Bar;" statements.
+
0.18_03
- Added support for the 'install_path' parameter, which allows custom
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.139
diff -u -r1.139 Base.pm
--- lib/Module/Build/Base.pm 7 Jul 2003 02:39:13 -0000 1.139
+++ lib/Module/Build/Base.pm 7 Jul 2003 22:08:40 -0000
@@ -1370,23 +1370,26 @@
foreach my $file (@pm_files) {
next if $file =~ m{^t/}; # Skip things in t/
- return unless $] >= 5.006; # perl 5.6 required for Module::Info
- return unless eval "use Module::Info 0.19; 1";
-
my $localfile = File::Spec->catfile( split m{/}, $file );
my $version = $self->version_from_file( $localfile );
-
- print "Scanning $localfile for packages\n";
- my $module = Module::Info->new_from_file( $localfile );
-
- foreach my $package ($module->packages_inside) {
- $out{$package} = {
- file => $file,
- version => $version,
- };
+
+ foreach my $package ($self->_packages_inside($localfile)) {
+ $out{$package}{file} = $file;
+ $out{$package}{version} = $version if defined $version;
}
}
return \%out;
+}
+
+sub _packages_inside {
+ # XXX this SUCKS SUCKS SUCKS! Damn you perl!
+ my ($self, $file) = @_;
+ my $fh = IO::File->new($file) or die "Can't read $file: $!";
+ my @packages;
+ while (defined(my $line = <$fh>)) {
+ push @packages, $1 if $line =~ /^[\s\{;]*package\s+([\w:]+)/;
+ }
+ return @packages;
}
sub make_tarball {
|
|
From: Ken W. <ke...@ma...> - 2003-07-07 21:36:38
|
On Monday, July 7, 2003, at 02:30 PM, Dave Rolsky wrote: > Ok, I just found a somwhat serious bug in the 0.18_04 release, and I > think > it's still present in the CVS version. > > If I run "./Build dist" on a new distro, it tries to load all the .pm > files in the MANIFEST file and scan them for packages via Module::Info. > > But if you've never installed the distro at hand, then loading the > various > module may fail unless the ./lib (or equivalent) directory is included > in > your lib path. > > I'm not sure if this is a new bug or if I've just not used > Module::Build > for an entirely new module, which is what provoked the problem. Argh, you're right. I wish Module::Info could override CORE::use() or something so it wouldn't have to run any other modules to get the info. In fact, looking through Module::Info now, I'm not sure it's really the right tool to be using here. It's really not very accurate in a lot of its information, and there's a case to be made that we should just be using the PAUSE/CPAN heuristics anyway. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-07 19:31:59
|
Ok, I just found a somwhat serious bug in the 0.18_04 release, and I think it's still present in the CVS version. If I run "./Build dist" on a new distro, it tries to load all the .pm files in the MANIFEST file and scan them for packages via Module::Info. But if you've never installed the distro at hand, then loading the various module may fail unless the ./lib (or equivalent) directory is included in your lib path. I'm not sure if this is a new bug or if I've just not used Module::Build for an entirely new module, which is what provoked the problem. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-07 17:31:33
|
Hi Randy etc., I think I just fixed the following bug on Win32: http://rt.cpan.org/Ticket/Display.html?id=2391 I've also added a test to t/xs.t that attempts to catch this situation. Could you (or someone else) try running the tests from the latest CVS (assuming anonymous-CVS ever catches up - it should be revision 1.8 of xs.t) on Win32 and see whether they work? Thanks. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-07 02:18:26
|
On Sun, 6 Jul 2003, Ken Williams wrote:
> >> Passes all tests on Debian unstable with 5.8.0 and 5.6.1, but there
> >> are
> >> some small problems with 5.00503.
> >
> > Both ideas sound good to me, I'll apply them to CVS.
>
> Say, Dave: it seems like it would be better to default 'script' like so:
>
> $c->{installsitescript} || $c->{installsitebin} ||
> $c->{installscript},
>
> rather than
>
> $c->{installsitescript} || $c->{installsitebin} || $c->{installbin},
>
> Do you have an 'installscript' on 5.005?
Yep, I do. I just didn't notice it ;)
There's a lot of entries in that Config.pm file ;)
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
|
|
From: Ken W. <ke...@ma...> - 2003-07-07 02:14:33
|
On Sunday, July 6, 2003, at 09:04 PM, Ken Williams wrote:
>
> On Thursday, July 3, 2003, at 11:04 PM, Dave Rolsky wrote:
>
>> On Thu, 3 Jul 2003, Ken Williams wrote:
>>
>>> I've released a new beta, 0.18_04, to cpan and sourceforge. It gets
>>> the 'install_base' parameter working, completing the design document
>>> I
>>> posted here a few days ago. I'd love it if people could test it out,
>>> by either/both of running the regression tests & using it to
>>> test/install their own Module::Build-using modules.
>>
>> Passes all tests on Debian unstable with 5.8.0 and 5.6.1, but there
>> are
>> some small problems with 5.00503.
>
> Both ideas sound good to me, I'll apply them to CVS.
Say, Dave: it seems like it would be better to default 'script' like so:
$c->{installsitescript} || $c->{installsitebin} ||
$c->{installscript},
rather than
$c->{installsitescript} || $c->{installsitebin} || $c->{installbin},
Do you have an 'installscript' on 5.005?
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-07-07 02:04:17
|
On Thursday, July 3, 2003, at 11:04 PM, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ken Williams wrote: > >> I've released a new beta, 0.18_04, to cpan and sourceforge. It gets >> the 'install_base' parameter working, completing the design document I >> posted here a few days ago. I'd love it if people could test it out, >> by either/both of running the regression tests & using it to >> test/install their own Module::Build-using modules. > > Passes all tests on Debian unstable with 5.8.0 and 5.6.1, but there are > some small problems with 5.00503. Both ideas sound good to me, I'll apply them to CVS. -Ken |
|
From: <ajs...@ya...> - 2003-07-04 09:24:19
|
Ken Williams <ke...@ma...> wrote:
> I've released a new beta, 0.18_04, to cpan and sourceforge. It gets
> the 'install_base' parameter working, completing the design document
> I posted here a few days ago. I'd love it if people could test it
> out, by either/both of running the regression tests & using it to
> test/install their own Module::Build-using modules.
>
> If it looks good, I'll make the 0.19 release.
Still passes OK on Windows.
Just a random thought. I noticed t/compat.t contains:
skip_test("Don't know how to invoke 'make'") unless $Config{make};
which is good. But what if $Config{make} points to something that
is not there? (I fear some Windows users may have $Config{make}
set to 'nmake' yet not have nmake installed).
Given that Module::Build does not depend on make, I think it would
be nice if compat.t could check if $Config{make} was indeed
available on the PATH and skip the tests if not -- instead of
failing, as it currently does. Does anyone know of a clean,
portable way to tell if a command is available on the PATH?
If not, a simple workaround is to start compat.t with the test:
$Config{make} force_do_it
Remember, force_do_it is a dummy target that does nothing, so this
command should always succeed with a return code of zero ... unless
$Config{make} is indeed unavailable.
/-\
http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.
|
|
From: Dave R. <au...@ur...> - 2003-07-04 06:40:00
|
On Fri, 4 Jul 2003, Mathieu Arnold wrote: > > > +-Le 03/07/2003 23:04 -0500, Dave Rolsky =E9crivait : > | When I ran Build.PL for the distro, it told me I needed Module::Info. > | So I went ahead and installed it, which worked fine under 5.00503. > | However, after doing this I get these test results: > > I believe there are a few remnants in Module::Info, there is a use 5.006 > and an "our" just after. I guess that removing the "our"s, adding a use > vars at the beginning, and also adding a dependency on File::Spec 0.82 wi= ll > be good, because the one with perl 5.00503 does not have rel2abs for > instance. No, the big problem is that most of the functionality requires the B::* modules. I think the fix is to simply not load it with 5.00503. -dave /*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D House Absolute Consulting www.houseabsolute.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/ |
|
From: Mathieu A. <ma...@ma...> - 2003-07-04 06:37:14
|
+-Le 03/07/2003 23:04 -0500, Dave Rolsky =E9crivait : | When I ran Build.PL for the distro, it told me I needed Module::Info. | So I went ahead and installed it, which worked fine under 5.00503. | However, after doing this I get these test results: I believe there are a few remnants in Module::Info, there is a use 5.006 and an "our" just after. I guess that removing the "our"s, adding a use vars at the beginning, and also adding a dependency on File::Spec 0.82 will be good, because the one with perl 5.00503 does not have rel2abs for instance. --=20 Mathieu Arnold |
|
From: Mathieu A. <ma...@ma...> - 2003-07-04 06:30:35
|
+-Le 03/07/2003 15:38 -0500, Ken Williams =E9crivait : |=20 | I understand your point, but compatibility with the PREFIX setting in | MakeMaker is not going to happen in Module::Build, at least not anytime | soon. The PREFIX behavior is mis-designed and often leads to people | installing things in places they didn't intend to install them. The | redesigned behavior of Module::Build is simpler, more flexible, and | safer. If we can find a way to bolt on a backwards-compatibility layer | for PREFIX that could be a good thing, but it will still be broken in | the same way PREFIX has always been broken, and I'm not inclined to | pursue it very aggressively for that reason. |=20 | If I can help you solve your specific problem in another way though, | don't hesitate to ask here. Better cooperation with packaging systems | is a major goal of Module::Build. Well, I do agree that PREFIX was a bit broken, but it's really useful, say, you want to make a new package, it's really easier to make install PREFIX=3D/var/tmp/something so that it gets there, and so that it's easier = to find witch files are installed :) I guess if I'm right, I should do a perl ./Build.PL destdir=3D/var/tmp/something and after, perl ./Build install would work out of the box for me, right ? I'm wondering because as I add perl modules to the FreeBSD ports tree, more and more use Module::Build, and we really need some knob to have them respect PREFIX :) If it means adding a second way of doing perl packages, I guess we'll do = it. --=20 Mathieu Arnold |
|
From: Dave R. <au...@ur...> - 2003-07-04 04:05:26
|
On Thu, 3 Jul 2003, Ken Williams wrote:
> I've released a new beta, 0.18_04, to cpan and sourceforge. It gets
> the 'install_base' parameter working, completing the design document I
> posted here a few days ago. I'd love it if people could test it out,
> by either/both of running the regression tests & using it to
> test/install their own Module::Build-using modules.
Passes all tests on Debian unstable with 5.8.0 and 5.6.1, but there are
some small problems with 5.00503.
When I ran Build.PL for the distro, it told me I needed Module::Info.
So I went ahead and installed it, which worked fine under 5.00503.
However, after doing this I get these test results:
t/basic.........ok
t/compat........ok 16/23Argument "0.18_04" isn't numeric in entersub at (eval 4) line 3.
t/compat........ok
t/runthrough....ok 8/26B::Module::Info,packages use failed with 255 saying:
use of backend Module::Info failed: Perl 5.006 required--this is only version 5.00503, stopped at /usr/local/perl5.00503/lib/site_perl/5.005/B/Utils.pm line 3.
BEGIN failed--compilation aborted at /usr/local/perl5.00503/lib/site_perl/5.005/B/Utils.pm line 3.
BEGIN failed--compilation aborted at /usr/local/perl5.00503/lib/site_perl/5.005/B/Module/Info.pm line 7.
BEGIN failed--compilation aborted at (eval 1) line 2.
at /root/cpan-5.00503/build/Module-Build-0.18_04/t/Sample/lib/Sample.pm line 0
BEGIN failed--compilation aborted.
t/runthrough....FAILED tests 17-18, 21-22
Failed 4/26 tests, 84.62% okay
t/signature.....skipped
all skipped: Skipping unless $ENV{TEST_SIGNATURE} is true
t/xs............ok
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/runthrough.t 26 4 15.38% 17-18 21-22
1 test skipped.
Failed 1/5 test scripts, 80.00% okay. 4/75 subtests failed, 94.67% okay.
The above errors are not the cause of the test failures, but they're
annoying and will not inspire end-user confidence ;)
Maybe just don't bother trying to load Module::Info "unless $] >= 5.006"?
Here's the verbose output for the failing tests:
not ok 17
# Test 17 got: 'Can't figure out where to install things of type 'script' at /root/cpan-5.00503/build/Module-Build-0.18_04/blib/lib/Module/Build/Base.pm line 1439.
' (t/runthrough.t at line 100)
# Expected: ''
Should have installed module as /root/cpan-5.00503/build/Module-Build-0.18_04/t/install_test/usr/local/perl5.00503/lib/site_perl/5.005/Sample.pm
not ok 18
# Failed test 18 in t/runthrough.t at line 105
Installing /root/cpan-5.00503/build/Module-Build-0.18_04/t/install_test/usr/local/perl5.00503/lib/5.00503/Sample.pm
Installing /root/cpan-5.00503/build/Module-Build-0.18_04/t/install_test/usr/local/perl5.00503/bin/script
ok 19
Should have installed module as /root/cpan-5.00503/build/Module-Build-0.18_04/t/install_test/usr/local/perl5.00503/lib/5.00503/Sample.pm
ok 20
not ok 21
# Test 21 got: 'Can't figure out where to install things of type 'script' at /root/cpan-5.00503/build/Module-Build-0.18_04/blib/lib/Module/Build/Base.pm line 1439.
' (t/runthrough.t at line 117)
# Expected: ''
Should have installed module as /root/cpan-5.00503/build/Module-Build-0.18_04/t/install_test/foo/bar/Sample.pm
not ok 22
# Failed test 22 in t/runthrough.t at line 120
The problem seems to be that my Config.pm does not define anything for
"installsitebin".
I have no idea why that should be the case. For versions 5.00503 and
5.6.1 of Perl on my machine, I compiled them myself, while 5.8.0 is
the Debian packaged version, so I suspect this is a general 5.00503
problem. I think you may need to just use "installbin" on 5.00503.
With the patch below my sig, all tests pass with 5.00503, though the
annoying noise from Module::Info persists.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
--- lib/Module/Build/Base.pm~ 2003-07-03 15:40:46.000000000 -0500
+++ lib/Module/Build/Base.pm 2003-07-03 23:04:26.000000000 -0500
@@ -99,7 +99,7 @@
lib => $c->{installsitelib},
arch => $c->{installsitearch},
bin => $c->{installsitebin},
- script => $c->{installsitescript} || $c->{installsitebin},
+ script => $c->{installsitescript} || $c->{installsitebin} || $c->{installbin},
bindoc => $c->{installsiteman1dir},
libdoc => $c->{installsiteman3dir},
},
@@ -107,7 +107,7 @@
lib => $c->{installvendorlib},
arch => $c->{installvendorarch},
bin => $c->{installvendorbin},
- script => $c->{installvendorscript} || $c->{installvendorbin},
+ script => $c->{installvendorscript} || $c->{installvendorbin} || $c->{installbin},
bindoc => $c->{installvendorman1dir},
libdoc => $c->{installvendorman3dir},
},
|
|
From: Dave R. <au...@ur...> - 2003-07-04 03:45:04
|
On Thu, 3 Jul 2003, Ken Williams wrote: > > On Thursday, July 3, 2003, at 02:25 PM, Dave Rolsky wrote: > > Oops, I was wrong. It respects your MANIFEST.SKIP file. But that > > _would_ > > need to be included in the released distro, which is probably worth > > noting > > somewhere in the docs. > > I think maybe the right thing to do would be to check somewhere in > new() for the presence of a SIGNATURE file, and for whether > Module::Signature is available, and if so, to attempt to verify the > signature. This would (typically) happen before any other files got > created, so it should generally work. > > However, the REAL right time to do it is BEFORE running the Build.PL > file, obviously - if you're already running scripts you downloaded off > the net, it's a little late to be checking signatures! So I'm thinking > we might want to not support this at all, on general principle. Good point. This should really be integrated in CPAN.pm and CPANPLUS. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-03 20:55:04
|
Hi, I've released a new beta, 0.18_04, to cpan and sourceforge. It gets the 'install_base' parameter working, completing the design document I posted here a few days ago. I'd love it if people could test it out, by either/both of running the regression tests & using it to test/install their own Module::Build-using modules. If it looks good, I'll make the 0.19 release. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-07-03 20:38:32
|
On Tuesday, July 1, 2003, at 08:16 AM, Mathieu Arnold wrote: > > > +-le 01/07/2003 07:40 -0500, Ken Williams =E9crivait : > | | Hi Mathieu, > | > | Thanks for your message. You probably actually want to use the =20 > 'destdir' > | parameter, which was created specifically to aid package managers. > | Recent versions of MakeMaker have a DESTDIR parameter now too, which = =20 > does > | basically the same thing as in Module::Build. > | > | Aside from that, the directory customization in released version of > | Module::Build is not very good. It's the top priority for version =20= > 0.19, > | and it's coming along well. You can see the current direction at > | =20 > http://sourceforge.net/mailarchive/=20 > forum.php?thread_id=3D2686103&forum_id=3D1 > | 0905 . > > I do not know, but it would be very good that using : > perl PREFIX=3D.... Makefile.PL > does indeed work. > It would have the FreeBSD's port work out of the box, without needs to = =20 > add > another hack. Hi Mathieu, I understand your point, but compatibility with the PREFIX setting in =20= MakeMaker is not going to happen in Module::Build, at least not anytime =20= soon. The PREFIX behavior is mis-designed and often leads to people =20 installing things in places they didn't intend to install them. The =20 redesigned behavior of Module::Build is simpler, more flexible, and =20 safer. If we can find a way to bolt on a backwards-compatibility layer =20= for PREFIX that could be a good thing, but it will still be broken in =20= the same way PREFIX has always been broken, and I'm not inclined to =20 pursue it very aggressively for that reason. If I can help you solve your specific problem in another way though, =20 don't hesitate to ask here. Better cooperation with packaging systems =20= is a major goal of Module::Build. -Ken |
7 messages has been excluded from this view by a project administrator.
