module-build-general Mailing List for Module::Build (Page 155)
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: Randy W. S. <Ra...@Th...> - 2003-10-09 02:56:51
|
On 10/8/2003 11:45 AM, Terrence Brannon wrote:
> gcc -shared -o XSTest.dll -Wl,--out-implib=libXSTest.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \
> -s -L/usr/local/lib lib/XSTest.o
Adding "-l$Config{libperl}" to the linker command should remove all the
unresolved references.
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: Paul J. <pa...@pj...> - 2003-10-08 20:18:14
|
... and I don't think it should. Here's a patch. I'm not subscribed, so please CC any replies to me. --- Module/Build/Base.pm.org 2003-10-07 17:12:31.000000000 +0200 +++ Module/Build/Base.pm 2003-10-08 22:09:07.000000000 +0200 @@ -972,9 +972,9 @@ $self->depends_on('code'); # Do everything in our power to work with all versions of Test::Harness - local ($Test::Harness::switches, - $Test::Harness::Switches, - $ENV{HARNESS_PERL_SWITCHES}) = ($p->{debugger} ? '-w -d' : '') x 3; + local ($Test::Harness::switches, $Test::Harness::Switches) = ('', ''); + local $ENV{HARNESS_PERL_SWITCHES} = $ENV{HARNESS_PERL_SWITCHES} . + ($p->{debugger} ? ' -w -d' : ''); local ($Test::Harness::verbose, $Test::Harness::Verbose, -- Paul Johnson - pa...@pj... http://www.pjcj.net |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2003-10-08 18:00:39
|
On Wed, Oct 08, 2003 at 08:45:35AM -0700, Terrence Brannon <met...@ur...> wrote: > Can't open blib/libdoc/Sample::Docs.3pm for writing: Invalid argument > at /home/metaperl/.cpan/build/Module-Build-0.20/blib/lib/Module/Build/Base.pm line 1286 I posted a patch for the manfile names a few weeks ago. > t/xs.t 11 2 18.18% 4 8 Someone needs to figure out how to translate ExtUtils::MM_Cygwin::init_linker and cflags into Module::Build terms. |
|
From: Terrence B. <met...@ur...> - 2003-10-08 15:45:42
|
This is Cygwin installed just 4 days ago (the latest). Here is the command-line used: ~/.cpan/build/Module-Build-0.20 $ ./Build test 2> Build.err > Build.out The output is quite large, so it is attached. |
|
From: Terrence B. <met...@ur...> - 2003-10-08 15:29:18
|
This first issue is trivial, but here it is using Perl-5.8.0.
~/.cpan/build/Module-Build-0.20 $ ls
Build Changes MANIFEST Makefile README lib
Build.PL INSTALL.txt META.yml Makefile.PL _build t
~/.cpan/build/Module-Build-0.20 $ less README
~/.cpan/build/Module-Build-0.20 $ perl Makefile.PL PREFIX=$PREFIX
perl Build.PL config=prefix=/home/metaperl/install
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Module-Build' version '0.20'
~/.cpan/build/Module-Build-0.20 $ ./Build 2> Build.err > Build.out
~/.cpan/build/Module-Build-0.20 $
--------------------------------
Build.err:
Can't open blib/libdoc/Module::Build::Platform::Unix.3pm for writing: No
such file or directory
at
/home/metaperl/.cpan/build/Module-Build-0.20/lib/Module/Build/Base.pm
line 1286
----------------------------------
Build.out:
lib/Module/Build/Platform/darwin.pm ->
blib/lib/Module/Build/Platform/darwin.pm
lib/Module/Build/Platform/MacOS.pm ->
blib/lib/Module/Build/Platform/MacOS.pm
lib/Module/Build/Compat.pm -> blib/lib/Module/Build/Compat.pm
lib/Module/Build/Platform/RiscOS.pm ->
blib/lib/Module/Build/Platform/RiscOS.pm
lib/Module/Build/Platform/VOS.pm -> blib/lib/Module/Build/Platform/VOS.pm
lib/Module/Build/Platform/Windows.pm ->
blib/lib/Module/Build/Platform/Windows.pm
lib/Module/Build/Platform/Unix.pm -> blib/lib/Module/Build/Platform/Unix.pm
lib/Module/Build/Platform/Amiga.pm ->
blib/lib/Module/Build/Platform/Amiga.pm
lib/Module/Build/Base.pm -> blib/lib/Module/Build/Base.pm
lib/Module/Build/Platform/EBCDIC.pm ->
blib/lib/Module/Build/Platform/EBCDIC.pm
lib/Module/Build/Platform/MPEiX.pm ->
blib/lib/Module/Build/Platform/MPEiX.pm
lib/Module/Build/Platform/VMS.pm -> blib/lib/Module/Build/Platform/VMS.pm
lib/Module/Build.pm -> blib/lib/Module/Build.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/Default.pm ->
blib/lib/Module/Build/Platform/Default.pm
Manifying blib/lib/Module/Build/Platform/Unix.pm ->
blib/libdoc/Module::Build::Platform::Unix.3pm
|
|
From: Ken_Williams v. R. <com...@rt...> - 2003-10-07 22:59:15
|
Full context and any attached attachments can be found at: <URL: http://rt.cpan.org/NoAuth/Bug.html?id=3928 > Test, written, bug closed. |
|
From: Chris D. <ch...@cl...> - 2003-10-07 17:58:55
|
I'm working on a subclass of Module::Build that is intended to package
non-Perl material. I've found M::B to be modular enough that this is
feasible without hacking *too* deeply (bravo to Ken and others!). One
aspect of this project includes adding platform-dependent compilation
routines. I accomplished this by simply saying something like:
-------- lib/Module/Build/Foo.pm -----------
package Module::Build::Foo;
our @ISA=qw(Module::Build);
...
sub ACTION_foo {
my $self = shift;
$self->compile_foo($_) for (@{ $self->find_foo_files })
}
...
package Module::Build::Base;
sub compile_foo {
print "Compiling foo is not supported on this platform\n';
}
package Module::Build::Platform::darwin;
sub compile_foo {
my ($self, $file) = @_;
$self->do_system("compileFoo", $file);
}
1;
---------------------------------------------
This seems to work great with one exception: META.yml now contains the
following lines
---------------------------------------
provides:
Module::Build::Base:
file: lib/Module/Build/Foo.pm
version: 0.10
Module::Build::Foo:
file: lib/Module/Build/Foo.pm
version: 0.10
Module::Build::Platform::darwin:
file: lib/Module/Build/Foo.pm
version: 0.10
---------------------------------------
I think this is bad thing, yes? I'm not providing those packages; I'm
just hacking them for my particular environment. Questions:
1) Is there a better way to add platform-specific extensions to M::B
subclasses without hacking ::Base and ::Platform::*?
2) Would explicitly declaring
sub Module::Build::Base::compile_foo { ... }
be better?
3) Is there a good way to tell ACTION_distmeta not to include those
hacked packages in the provides hash?
Thanks,
Chris
P.S. In M::B v0.20, ACTION_distmeta has an out-of-date warning message
about Module::Info. I happened to notice that in my research for the
above questions. I didn't check CVS to see if it's already been fixed.
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
ch...@cl..., 294-7900, 211 S Paterson, Madison WI 53703
|
|
From: Ken_Williams v. R. <com...@rt...> - 2003-10-02 18:18:19
|
Full context and any attached attachments can be found at: <URL: http://rt.cpan.org/NoAuth/Bug.html?id=3928 > Thanks, I've now fixed this bug in CVS but I need to write a test for it. -Ken |
|
From: Stephen J. S. <sj...@kh...> - 2003-10-02 13:44:48
|
Line 61 of runthrough.t calls check_installed_status() and checks for a
true result. check_installed_status() returns a hash which always
evaluates to true.
Maybe this hasn't been caught because t/Sample/META.yml is part of the
distribution? Maybe the test code should unlink() it before invoking
distdir?
The below patch uses the same check that Base.pm uses for a similar
purpose. There are other approaches of course.
diff -uNr Module-Build-0.20.orig/t/runthrough.t Module-Build-0.20/t/runthrough.t
--- Module-Build-0.20.orig/t/runthrough.t 2003-08-26 14:49:15.000000000 -0400
+++ Module-Build-0.20/t/runthrough.t 2003-10-02 09:18:45.000000000 -0400
@@ -58,7 +58,7 @@
print $output;
print "^^^^^^^^^^^^^^^^^^^^^ Sample/test.pl output ^^^^^^^^^^^^^^^^^^^^^\n";
-if ($build->check_installed_status('YAML', 0)) {
+if (eval {require YAML; 1}) {
eval {$build->dispatch('disttest')};
ok $@, '';
End of Patch.
|
|
From: Stephen J. S. <sj...@kh...> - 2003-10-02 05:15:24
|
On Wed, 2003-10-01 at 15:50, Brett Kettlewell wrote (in icky html): > t/xs............ok 6/11Can't exec "gcc'": No such file or directory at That single quote in "gcc'" looks suspicious. Does "perl -V:cc" or "perl -V:ld" show anything weird? I have recently installed version 0.20 of Module::Build on Red Hat 9 without any problems. Well, no problems after I set LANG=C. |
|
From: Mark S. <ma...@su...> - 2003-10-01 22:10:30
|
Hello, Today I looked into seeing what the "docs" action does. When I ran it, the output looks identical to just running "./Build". So I looked at the code. It looks like they are in fact doing the exact same thing. If you don't specify an action, "build" is the default. "build" calls the "code" action, and then "docs" action. If you call the "docs" action directly, it depends on the "code" action, so again the "code" ation gets called, followed by the "docs" action. So it doesn't seem an incredibly useful action at the moment. :). It would seem more useful if you could build the docs without depending on the code being built, but I'm not sure if that will make sense from a technical perspective. At any rate, the docs could say something like: docs Builds all the man pages for the binary and library POD. This action depends on the code being built, and will call the 'code' action if it hasn't already run. By default this action gives the exact seems results as simply running "./Build". Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer ma...@su... Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . |
|
From: Brett K. <Br...@tc...> - 2003-10-01 19:50:43
|
I don't write Perl but I'm installing modules for an application (RT) on a Redhat9 server which has dependencies on a myriad of Perl modules. I've loaded a ton of modules, but the last two are both dependant on Module::Build, and I can't get that to load. I've tried to install from doing a "% perl MCPAN -e 'install Module::Build'" and from actually downloading it, un-tarring it, creating the script, making, and testing it. Both ways I get the same errors: t/xs............ok 6/11Can't exec "gcc'": No such file or directory at /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/Build/Base. pm line 1917, <File0000> line 14. error building lib/XSTest.o from 'lib/XSTest.so' at /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/Build/Base. pm line 1797, <File0000> line 14. t/xs............NOK 8# Test 8 got: 'error building lib/XSTest.o from 'lib/XSTest.so' at /home/drives/s/Brett/Downloads/Module-Build-0.20/blib/lib/Module/Build/Base. pm line 1797, <File0000> line 14. ' (t/xs.t at line 50) # Expected: '' # t/xs.t line 50 is: ok $@, ''; Of my 50 or so module dependencies, this is the last one I have to install, and then I can get on to configuring the application. Has anyone received these errors when doing their make test? Is there a workaround? Brett M. Kettlewell Trauner, Cohen & Thomas Br...@tc... 888-696-1900 x1023 |
|
From: Bart P. <ba...@la...> - 2003-09-29 19:50:42
|
I'm having trouble running Module::Build 0.20 tests on a newly
built version of perl 5.8.1 on AIX 4.3. I'm seeing this during a
"Build test" ...
<everything ok up to this point>
t/versions......ok
t/xs............ok 3/11ld: 0706-003 Cannot find or read import
file: $(PERL_INC)/perl.exp
ld:accessx(): A file or directory in the path name does
not exist.
ld: 0706-004 Cannot find or read export file: $(BASEEXT).exp
ld:accessx(): A file or directory in the path name does
not exist.
# Test 4 got: 'error building lib/XSTest.o from 'lib/XSTest.so'
at /usr/local/src/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797.
' (t/xs.t at line 33)
# Expected: ''
# t/xs.t line 33 is: ok $@, '';
t/xs............ok 6/11ld: 0706-003 Cannot find or read import
file: $(PERL_INC)/perl.exp
ld:accessx(): A file or directory in the path name does
not exist.
ld: 0706-004 Cannot find or read export file: $(BASEEXT).exp
ld:accessx(): A file or directory in the path name does
not exist.
error building lib/XSTest.o from 'lib/XSTest.so' at
/usr/local/src/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797.
t/xs............ok 7/11ld: 0706-003 Cannot find or read import
file: $(PERL_INC)/perl.exp
ld:accessx(): A file or directory in the path name does
not exist.
ld: 0706-004 Cannot find or read export file: $(BASEEXT).exp
ld:accessx(): A file or directory in the path name does
not exist.
# Test 8 got: 'error building lib/XSTest.o from 'lib/XSTest.so'
at /usr/local/src/Module-Build-0.20/blib/lib/Module/Build/Base.pm
line 1797.
' (t/xs.t at line 50)
# Expected: ''
# t/xs.t line 50 is: ok $@, '';
t/xs............FAILED tests 4, 8
<...>
I noticed that it's using the literal "$(PERL_INC)/perl.exp" and
"$(BASEEXT).exp" strings during the 'ld' rather than
interpolating them.
At first I thought that I had built perl incorrectly, since these
literal values are in the "perl -V" output for lddlflags (see
below). After looking at the vendor's built-in perl on a
different machine (5.6.0), it appears that 'lddlflags' has these
two values in there as well.
Thanks,
Bart
ba...@la...
=====
Here's the perl -V output...
Summary of my perl5 (revision 5.0 version 8 subversion 1)
configuration:
Platform:
osname=aix, osvers=4.3.3.0, archname=aix-64int
uname='aix foof 3 4 0000f04f4c00 '
config_args='-Dprefix=/usr/local/perl -de -Uinstallusrbinperl
-Ui_db -Dpager=/usr/bin/more -Duse64bitint'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define
usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE
-D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN
-q32 -D_LARGE_FILES -qlonglong',
optimize='-O',
cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
-qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN'
ccversion='5.0.2.0', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8,
byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=8
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='ld', ldflags =' -brtl -L/usr/local/lib -b32'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lc -lbsd
perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lc -lbsd
libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
-bE:/usr/local/perl/lib/5.8.1/aix-64int/CORE/perl.exp'
cccdlflags=' ', lddlflags=' -bhalt:4 -bM:SRE
-bI:$(PERL_INC)/perl.exp -bE:$(BASEEXT).exp -bnoentry -lc
-L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Built under aix
Compiled at Sep 25 2003 15:55:24
@INC:
/usr/local/perl/lib/5.8.1/aix-64int
/usr/local/perl/lib/5.8.1
/usr/local/perl/lib/site_perl/5.8.1/aix-64int
/usr/local/perl/lib/site_perl/5.8.1
/usr/local/perl/lib/site_perl
.
|
|
From: Steve P. <sp...@qu...> - 2003-09-29 10:23:58
|
Hi Scott, Ken, A lot of the people I've spoken to about M::B have pointed out that it doesn't do recursive builds yet, and for some of them it's a deciding factor to stick with MakeMaker. I'd say this is something that needs to go on the TODO list. -Steve On Friday, September 26, 2003, at 05:57 pm, Scott Cain wrote: > Hello, > > I just wanted to follow up with a simple example to illustrate what Ken > is talking about here. If I have the following directory structure: > > Top/ > Makefile.PL > MANIFEST > sub1/ > Makefile.PL > sub2/ > Makefile.PL > > and I execute `perl Makefile.PL`, then it magically recognizes that > there are Makefile.PL files in subdirectories and creates Makefiles for > those directories. If I replace Makefile.PL with Build.PL, that magic > no longer appears to happen. Additionally, `perl Build.PL` croaks > because there is no lib/ directory, and in the above scheme, there may > not always be a lib directory. I've attached two tarballs with > Makefile.PLs and Build.PLs to illustrate. > > Thanks, > Scott > > > On Thu, 2003-09-25 at 15:37, Ken Y. Clark wrote: >> All, >> >> We're discussing use of Module::Build for GMOD (http://www.gmod.org/), >> a rather large umbrella for many other projects. Currently, each part >> of GMOD is a separate download and build, some parts of which are Perl >> and some Java. The goal is to integrate them more fully one day, >> perhaps providing and installation process wherein you say "perl >> Build.PL --enable=foo --enable=bar" for each piece you want, and then >> the builds for each project go from there. Is it possible to have >> M::B build recursively through subdirectories? Further, what would it >> be like if some projects built differently from others, e.g., some >> still use ExtUtils::MakeMaker and some M::B? >> >> ky > -- > ----------------------------------------------------------------------- > - > Scott Cain, Ph. D. > ca...@cs... > GMOD Coordinator (http://www.gmod.org/) > 216-392-3087 > Cold Spring Harbor Laboratory > <Make_test.tar.gz><module_build.tar.gz> |
|
From: Steve P. <sp...@qu...> - 2003-09-29 10:04:24
|
On Thursday, September 25, 2003, at 10:00 am, Steve Purkis wrote: > As an aside, I always thought it would be a bit more useful to > generate HTML manpages on Win32 & friends, considering they don't have > a 'man' tool by default. I suppose cygwin supplies one, so it's not a > problem there. But there might be a case for an option that lets the > user build HTML or MAN pages. For example, ACTION_docs could be split up into ACTION_manpages, ACTION_html_docs: ./Build html_docs ./Build manpages And there could be config parameters set for each (with sensible defaults for each OS) that ACTION_docs checked before trying to do anything. What do people think: a useful idea, or feature creep? -Steve |
|
From: <iv...@ab...> - 2003-09-29 09:47:24
|
I am making a very large recursive subclassing, all recursive calls use use lib "."; I have file called Config.pm which duplicate Module::Build internal file.... It will be good to rename the distribution files to some iregular names _C_onfig.pm so not to duplicate and mismatch with the user distribution. |
|
From: Steve P. <sp...@qu...> - 2003-09-29 09:44:39
|
Hi Mark,
That's not a bad idea - I've seen scripts that do similar things with
File::Find::Rule, and they can be quite useful. Still, I'd say the
developer can check the output of './Build docs' for errors, though I
agree it's not as nice an interface. Your argument might be more
persuasive with a patch?
In terms of implementation, you'd want to run it on the same pod files
as those found in manify_bin_pods() and manify_lib_pods(). Which
likely means you'd need to factor out methods like _lib_pods() and
_bin_pods() to avoid re-inventing the wheel, something like:
sub _bin_pods {
my $self = shift;
return $self->_find_pods($self->{properties}{bindoc_dirs});
}
And write an ACTION to run those through Test::Pod.
-Steve
On Sunday, September 28, 2003, at 05:23 pm, Mark Stosberg wrote:
> Hello,
>
> You've probably noticed the new feature on search.cpan.org that now
> explains POD errors found in Perl modules as part of the documentation
> display. I think is useful. Something that would complement this would
> be the ability to easily test all the pod when running "./Build test",
> rather than noticing the errors after they have been made public.
>
> This is already fairly easy by using the below test script.
>
> However, there still seems like a better solution should be available
> than including the same test script in every module distribution.
>
> Instead, this seems like a service that it could be reasonable for
> Module::Build to offer.
>
> Perhaps running "./Build testpod" could run this test.
>
> Although this wouldn't be run as part of the standard install process I
> think that's OK. What seems important is that the /developer/ be able
> to
> run the test, while it's less important to make this easy for the
> /user/ to test pod.
>
>
> Mark
>
> --
> http://mark.stosberg.com/
>
> #####
>
> /usr/src/.cpanplus/5.8.0/build/Data-FormValidator-3.11/t/99_pod.t
> use Test::More;
>
> # Check our Pod
> # The test was provided by Andy Lester,
> # who stole it from Brian D. Foy
> # Thanks to both !
>
> use File::Spec;
> use File::Find;
> use strict;
>
> eval {
> require Test::Pod;
> Test::Pod->import;
> };
>
> my @files;
>
> if ($@) {
> plan skip_all => "Test::Pod required for testing POD";
> }
> elsif ($Test::Pod::VERSION < 0.95) {
> plan skip_all => "Test::Pod 0.95 required for testing POD";
> }
> else {
> my $blib = File::Spec->catfile(qw(blib lib));
> find(\&wanted, $blib, 'bin');
> plan tests => scalar @files;
> foreach my $file (@files) {
> pod_file_ok($file);
> }
> }
>
> sub wanted {
> push @files, $File::Find::name if /\.p(l|m|od)$/;
> }
>
> __END__
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Steve P. <sp...@qu...> - 2003-09-29 09:34:52
|
Hi Yitzchak,
Apologies for the delay, the end of last week was a bit hectic..
On Thursday, September 25, 2003, at 11:50 am, Yitzchak Scott-Thoennes
wrote:
> On Thu, Sep 25, 2003 at 10:00:14AM +0100, Steve Purkis
> <sp...@qu...> wrote:
>> On Wednesday, September 24, 2003, at 06:05 pm, Yitzchak
>> Scott-Thoennes
>> wrote:
>>
>>> On Wed, Sep 24, 2003 at 05:29:23PM +0100, Steve Purkis
>>> <sp...@qu...> wrote:
>>>> On Wednesday, September 24, 2003, at 07:06 am, Yitzchak
>>>> Scott-Thoennes
>>>> wrote:
>>>>
>>>>> Couldn't install Module::Build...the manpage names contain colons.
>>>>> Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and
>>>>> MM_OS2
>>>>> ($^O eq 'uwin' and 'os2', respectively) also use '.', but have no
>>>>> special code in Module::Build. MakeMaker uses '__' for DOS,
>>>>> Module::Build uses '.' (via Platform/Windows.pm).
>>>>
>>>> Might make sense to use '__' for cygwin then, to preserve MM
>>>> compatibility.
>>>
>>> I assume you mean DOS, not cygwin. cygwin should use '.'.
>>
>> Actually, I was a bit confused there. I meant cygwin, but then I've
>> just looked at MM_Cygwin, which inherits its manpage separator from
>> MM_Unix ('::' again), so M::B was backwards compatible to begin with.
>> Perhaps MM_Cygwin's manpage generation is broken?
>
> I don't know if we are looking at the same thing. I see this in
> MakeMaker:
You're quite right - I'm looking at EU::MM v6.05, and that's got an
older MM_Cygwin.pm (v1.04). Couldn't see a reference to it in the
Changes file, but it looks like that's one thing that's changed.
So it was backwards compat with a broken MM_Cygwin. Oops :).
>> As an aside, I always thought it would be a bit more useful to
>> generate
>> HTML manpages on Win32 & friends, considering they don't have a 'man'
>> tool by default. I suppose cygwin supplies one, so it's not a problem
>> there. But there might be a case for an option that lets the user
>> build HTML or MAN pages.
>
> I'd think whether to install HTML would be a separate option, unrelated
> to man pages.
Yeah - that discussion really belongs in a separate thread.
>>>> I didn't see a Module::Build subclass for the others
>>>> you've mentioned, so I left them out of the original patch[1].
>>>>
>>>> Perhaps stubs for them should be created too?
>>>
>>> Only if someone is going to try them. I don't even know what uwin
>>> is.
>>
>> Point taken.
>
> What are the plans for integrating into the core? As soon as you do
> that, the people who maintain the various ports will be pretty much
> forced to get things working.
I imagine the CPAN Testers and p5p will be involved, but I don't know
what the plan is. Ken's your best bet for that question.
( Still, it will most likely be in the core by 5.10.0 - if you haven't
already, see:
http://search.cpan.org/dist/perl-5.8.1/pod/
perldelta.pod#Future_Directions )
-Steve
|
|
From: Mark S. <ma...@su...> - 2003-09-28 20:08:06
|
You may be aware of Devel::Cover, a new module that with quality
assurance by reporting on how thoroughly a test suite is covering the
code in a Perl module.
However, I noticed that when I used the suggested syntax with a module
that used Module::Build, it generated an empty report. I tried this with
Data::FormValidator using the recommended syntax:
HARNESS_PERL_SWITCHES=-MDevel::Cover make test
cover -report html
I found this code from Richard Clamp on the web which allowed me to
use Devel::Cover with module build. It adds a new 'cover' target the Build
script:
sub ACTION_cover {
my $self = shift;
$self->depends_on('build');
system qw( cover -delete );
# sometimes we get failing tests, which makes Test::Harness
# die. catch that
eval {
local $ENV{PERL5OPT} = "-MDevel::Cover=-summary,0";
$self->ACTION_test(@_);
};
system qw( cover -report html );
}
####
This seems me like something that could eventually be suitable for the
core Module::Build. In the meantime, enjoy using the above code
to test your own module's test coverage.
Here are some real reports I generated with it:
Data::FormValidator
http://mark.stosberg.com/dfv/cover_db/cover_db.html
DBD::Pg
http://mark.stosberg.com/Tech/perl/dbd_pg/cover_db/cover_db.html
Mark
--
http://mark.stosberg.com/
|
|
From: Mark S. <ma...@su...> - 2003-09-28 16:23:10
|
Hello, You've probably noticed the new feature on search.cpan.org that now explains POD errors found in Perl modules as part of the documentation display. I think is useful. Something that would complement this would be the ability to easily test all the pod when running "./Build test", rather than noticing the errors after they have been made public. This is already fairly easy by using the below test script. However, there still seems like a better solution should be available than including the same test script in every module distribution. Instead, this seems like a service that it could be reasonable for Module::Build to offer. Perhaps running "./Build testpod" could run this test. Although this wouldn't be run as part of the standard install process I think that's OK. What seems important is that the /developer/ be able to run the test, while it's less important to make this easy for the /user/ to test pod. Mark -- http://mark.stosberg.com/ ##### /usr/src/.cpanplus/5.8.0/build/Data-FormValidator-3.11/t/99_pod.t use Test::More; # Check our Pod # The test was provided by Andy Lester, # who stole it from Brian D. Foy # Thanks to both ! use File::Spec; use File::Find; use strict; eval { require Test::Pod; Test::Pod->import; }; my @files; if ($@) { plan skip_all => "Test::Pod required for testing POD"; } elsif ($Test::Pod::VERSION < 0.95) { plan skip_all => "Test::Pod 0.95 required for testing POD"; } else { my $blib = File::Spec->catfile(qw(blib lib)); find(\&wanted, $blib, 'bin'); plan tests => scalar @files; foreach my $file (@files) { pod_file_ok($file); } } sub wanted { push @files, $File::Find::name if /\.p(l|m|od)$/; } __END__ |
|
From: Scott C. <ca...@cs...> - 2003-09-26 19:44:43
|
Hello,
I just wanted to follow up with a simple example to illustrate what Ken
is talking about here. If I have the following directory structure:
Top/
Makefile.PL
MANIFEST
sub1/
Makefile.PL
sub2/
Makefile.PL
and I execute `perl Makefile.PL`, then it magically recognizes that
there are Makefile.PL files in subdirectories and creates Makefiles for
those directories. If I replace Makefile.PL with Build.PL, that magic
no longer appears to happen. Additionally, `perl Build.PL` croaks
because there is no lib/ directory, and in the above scheme, there may
not always be a lib directory. I've attached two tarballs with
Makefile.PLs and Build.PLs to illustrate.
Thanks,
Scott
On Thu, 2003-09-25 at 15:37, Ken Y. Clark wrote:
> All,
>
> We're discussing use of Module::Build for GMOD (http://www.gmod.org/),
> a rather large umbrella for many other projects. Currently, each part
> of GMOD is a separate download and build, some parts of which are Perl
> and some Java. The goal is to integrate them more fully one day,
> perhaps providing and installation process wherein you say "perl
> Build.PL --enable=foo --enable=bar" for each piece you want, and then
> the builds for each project go from there. Is it possible to have
> M::B build recursively through subdirectories? Further, what would it
> be like if some projects built differently from others, e.g., some
> still use ExtUtils::MakeMaker and some M::B?
>
> ky
--
------------------------------------------------------------------------
Scott Cain, Ph. D. ca...@cs...
GMOD Coordinator (http://www.gmod.org/) 216-392-3087
Cold Spring Harbor Laboratory
|
|
From: Ken W. <ke...@ma...> - 2003-09-25 14:18:13
|
Hi,
I had a quick look at the man3page code surrounding the current
discussion of separator strings, and I just applied the following
patch. It does two things:
* Fixes a problem with File::Spec usage in man3page_name, which wasn't
dealing with the volume or file portions correctly for certain platforms
* No longer assumes that pods are under 'blib/lib' or 'blib/arch'
It doesn't have much bearing on your current discussion of separators,
but since it's the same area of code I thought I'd let you know.
-Ken
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.197
retrieving revision 1.198
diff -u -r1.197 -r1.198
--- lib/Module/Build/Base.pm 21 Sep 2003 03:30:49 -0000 1.197
+++ lib/Module/Build/Base.pm 25 Sep 2003 14:10:33 -0000 1.198
@@ -1302,8 +1302,8 @@
my $mandir = File::Spec->catdir( $self->blib, 'libdoc' );
File::Path::mkpath( $mandir, 0, 0777 );
- foreach my $file (keys %$files) {
- my $manpage = $self->man3page_name( $file ) . '.' .
$self->{config}{man3ext};
+ while (my ($file, $relfile) = each %$files) {
+ my $manpage = $self->man3page_name( $relfile ) . '.' .
$self->{config}{man3ext};
my $outfile = File::Spec->catfile( $mandir, $manpage);
next if $self->up_to_date( $file, $outfile );
print "Manifying $file -> $outfile\n";
@@ -1318,7 +1318,7 @@
foreach my $spec (@$dirs) {
my $dir = $self->localize_file_path($spec);
next unless -e $dir;
- do { $files{$_} = $_ if $self->contains_pod( $_ ) }
+ do { $files{$_} = File::Spec->abs2rel($_, $dir) if
$self->contains_pod( $_ ) }
for @{ $self->rscan_dir( $dir ) };
}
return \%files;
@@ -1348,17 +1348,13 @@
# -spurkis
sub man3page_name {
my $self = shift;
- my $file = File::Spec->canonpath( shift ); # clean up file path
- my @dirs = File::Spec->splitdir( $file );
-
- # more clean up - assume all man3 pods are under 'blib/lib' or
'blib/arch'
- # to avoid the complexity found in Pod::Man::begin_pod()
- shift @dirs while ($dirs[0] =~ /^(?:blib|lib|arch)$/i);
-
- # remove known exts from the base name
- $dirs[-1] =~ s/\.p(?:od|m|l)\z//i;
-
- return join( $self->manpage_separator, @dirs );
+ my ($vol, $dirs, $file) = File::Spec->splitpath( shift );
+ my @dirs = File::Spec->splitdir( File::Spec->canonpath($dirs) );
+
+ # Remove known exts from the base name
+ $file =~ s/\.p(?:od|m|l)\z//i;
+
+ return join( $self->manpage_separator, @dirs, $file );
}
sub manpage_separator {
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2003-09-25 10:51:15
|
On Thu, Sep 25, 2003 at 10:00:14AM +0100, Steve Purkis <sp...@qu...> wrote:
> On Wednesday, September 24, 2003, at 06:05 pm, Yitzchak Scott-Thoennes
> wrote:
>
> >On Wed, Sep 24, 2003 at 05:29:23PM +0100, Steve Purkis
> ><sp...@qu...> wrote:
> >>On Wednesday, September 24, 2003, at 07:06 am, Yitzchak
> >>Scott-Thoennes
> >>wrote:
> >>
> >>>Couldn't install Module::Build...the manpage names contain colons.
> >>>Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2
> >>>($^O eq 'uwin' and 'os2', respectively) also use '.', but have no
> >>>special code in Module::Build. MakeMaker uses '__' for DOS,
> >>>Module::Build uses '.' (via Platform/Windows.pm).
> >>
> >>Might make sense to use '__' for cygwin then, to preserve MM
> >>compatibility.
> >
> >I assume you mean DOS, not cygwin. cygwin should use '.'.
>
> Actually, I was a bit confused there. I meant cygwin, but then I've
> just looked at MM_Cygwin, which inherits its manpage separator from
> MM_Unix ('::' again), so M::B was backwards compatible to begin with.
> Perhaps MM_Cygwin's manpage generation is broken?
I don't know if we are looking at the same thing. I see this in
MakeMaker:
sthoenna@DHX98431 /usr/lib/perl5/5.8.0/ExtUtils
$ fgrep -A3 'sub replace_manpage_separator' MM*
MM_Cygwin.pm:sub replace_manpage_separator {
MM_Cygwin.pm- my($self, $man) = @_;
MM_Cygwin.pm- $man =~ s{/+}{.}g;
MM_Cygwin.pm- return $man;
--
MM_DOS.pm:sub replace_manpage_separator {
MM_DOS.pm- my($self, $man) = @_;
MM_DOS.pm-
MM_DOS.pm- $man =~ s,/+,__,g;
--
MM_OS2.pm:sub replace_manpage_separator {
MM_OS2.pm- my($self,$man) = @_;
MM_OS2.pm- $man =~ s,/+,.,g;
MM_OS2.pm- $man;
--
MM_UWIN.pm:sub replace_manpage_separator {
MM_UWIN.pm- my($self, $man) = @_;
MM_UWIN.pm-
MM_UWIN.pm- $man =~ s,/+,.,g;
--
MM_Unix.pm:sub replace_manpage_separator {
MM_Unix.pm- my($self,$man) = @_;
MM_Unix.pm-
MM_Unix.pm- $man =~ s,/+,::,g;
--
MM_VMS.pm:sub replace_manpage_separator {
MM_VMS.pm- my($self,$man) = @_;
MM_VMS.pm- $man = unixify($man);
MM_VMS.pm- $man =~ s#/+#__#g;
--
MM_Win32.pm:sub replace_manpage_separator {
MM_Win32.pm- my($self,$man) = @_;
MM_Win32.pm- $man =~ s,/+,.,g;
MM_Win32.pm- $man;
and I do get manpages with . in them.
> As an aside, I always thought it would be a bit more useful to generate
> HTML manpages on Win32 & friends, considering they don't have a 'man'
> tool by default. I suppose cygwin supplies one, so it's not a problem
> there. But there might be a case for an option that lets the user
> build HTML or MAN pages.
I'd think whether to install HTML would be a separate option, unrelated
to man pages.
> >>I didn't see a Module::Build subclass for the others
> >>you've mentioned, so I left them out of the original patch[1].
> >>
> >>Perhaps stubs for them should be created too?
> >
> >Only if someone is going to try them. I don't even know what uwin is.
>
> Point taken.
What are the plans for integrating into the core? As soon as you do
that, the people who maintain the various ports will be pretty much
forced to get things working.
|
|
From: Steve P. <sp...@qu...> - 2003-09-25 09:08:00
|
On Wednesday, September 24, 2003, at 06:05 pm, Yitzchak Scott-Thoennes
wrote:
> On Wed, Sep 24, 2003 at 05:29:23PM +0100, Steve Purkis
> <sp...@qu...> wrote:
>> On Wednesday, September 24, 2003, at 07:06 am, Yitzchak
>> Scott-Thoennes
>> wrote:
>>
>>> Couldn't install Module::Build...the manpage names contain colons.
>>> Patch below fixes it. Looking at MakeMaker, I see MM_UWIN and MM_OS2
>>> ($^O eq 'uwin' and 'os2', respectively) also use '.', but have no
>>> special code in Module::Build. MakeMaker uses '__' for DOS,
>>> Module::Build uses '.' (via Platform/Windows.pm).
>>
>> Might make sense to use '__' for cygwin then, to preserve MM
>> compatibility.
>
> I assume you mean DOS, not cygwin. cygwin should use '.'.
Actually, I was a bit confused there. I meant cygwin, but then I've
just looked at MM_Cygwin, which inherits its manpage separator from
MM_Unix ('::' again), so M::B was backwards compatible to begin with.
Perhaps MM_Cygwin's manpage generation is broken?
As an aside, I always thought it would be a bit more useful to generate
HTML manpages on Win32 & friends, considering they don't have a 'man'
tool by default. I suppose cygwin supplies one, so it's not a problem
there. But there might be a case for an option that lets the user
build HTML or MAN pages.
>> I didn't see a Module::Build subclass for the others
>> you've mentioned, so I left them out of the original patch[1].
>>
>> Perhaps stubs for them should be created too?
>
> Only if someone is going to try them. I don't even know what uwin is.
Point taken.
-Steve
|
|
From: Mark S. <ma...@su...> - 2003-09-24 20:07:42
|
Hello, I have a question about the best way to handle a module dependency issue. I maintain Data::FormValidator. To use its basic and most common functionality, it requires no other modules. However, to use some it's bells-and-whistles features, it requires about 5 other modules for various things... which my have their own dependencies. Recently a bug was filed against the module for "too many dependencies", so I'm looking to possibly slim down what's required by default, while still handle the bells-and-whistles cases gracefully, somehow. Any recommended solutions for this kind of case? One option seems to declare only the more critical dependencies at install time. If there is an attempt to access a missing module, a "Module not installed..." message could be emitted. That seems like it has its own problems, though. I think my personal tendency is error on the side of having module dependencies. Depending on other modules sounds like "code reuse" to me, which seems like a good thing. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer ma...@su... Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . . --_----------=_1064433047325650-- |
7 messages has been excluded from this view by a project administrator.
