module-build-general Mailing List for Module::Build (Page 166)
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: Uri G. <ur...@st...> - 2003-06-30 19:15:23
|
>>>>> "KW" == Ken Williams <ke...@ma...> writes: KW> =item script KW> Programs written in pure Perl. Try to make these as small as possible KW> - put the code into modules whenever possible. why do scripts have to be small? is there a real size limit? if not, you shouldn't editorialize on how to write scripts. some scripts just need to be long or not use many modules. KW> =item bin KW> "Architecture-dependent" programs, i.e. compiled C code or something. KW> Pretty rare to see this in a perl distribution, but it happens. xs (or now inline::) code isn't that rare. i would drop the last line. you could make a comment about these programs use XS or inline::c/cpp or other cpu architecture dependent stuff. also what compiler will be chosen for that? i didn't see any override options in this doc. KW> =item bindoc KW> Documentation for the stuff in C<script> and C<bin>. Usually KW> generated from the POD in those files. Under Unix, these are manual KW> pages belonging to the 'man1' category. can the pod be generated from another command? stem will have a stem2pod command that needs to be run since some of the pod is autogenerated from attribute specifications. KW> The default destinations for these installable things come from KW> entries in your system's C<Config.pm>. You can select from three KW> different sets of default locations by setting the C<installdirs> KW> parameter as follows: this needs to be explained a litte more i think. make it clear in the text that the choices are core/site/vendor and not lib/arch/etc/. the chart shows that but it could be more explicit. never underestimate the dumbnitude of people doing cpan installs. :) KW> 'installdirs' set to: KW> core site vendor KW> uses the following defaults from Config.pm: KW> lib => installprivlib installsitelib installvendorlib KW> arch => installarchlib installsitearch installvendorarch KW> script => installscript installsitebin installvendorbin KW> bin => installbin installsitebin installvendorbin KW> libdoc => installman3dir installsiteman3dir installvendorman3dir KW> bindoc => installman1dir installsiteman1dir installvendorman1dir KW> perl Build.PL destdir=/tmp/foo KW> or KW> Build install destdir=/tmp/foo this is the first time you show how these params are set. you should have an example at the top and examples of each param as you get to them. when i first read this i was asking 'where do i set these? in the Build.PL or what? overall, i like it a lot. it is the best high level picture of build.pl i have seen so far. uri -- Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org |
|
From: Dave R. <au...@ur...> - 2003-06-30 18:05:09
|
On Mon, 30 Jun 2003, Ken Williams wrote: > I've decided on some semantics for how to specify installation paths > using Module::Build. Here's the POD I've written for it, please give > me feedback if you have any. Looks good to me. I actually understand it, which is something I can't say for MM's PREFIX and LIB stuff ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Nicholas C. <ni...@cc...> - 2003-06-30 17:52:01
|
On Mon, Jun 30, 2003 at 12:11:41PM -0500, Ken Williams wrote: > I've decided on some semantics for how to specify installation paths > using Module::Build. Here's the POD I've written for it, please give > me feedback if you have any. Seems good, and seems to make sense on a quick read through Nicholas Clark |
|
From: Dave R. <au...@ur...> - 2003-06-30 17:23:09
|
Ken, are you really, really, really sure you checked this into the right place? It's still not visible via anon cvs or the the web cvs, which just seems really weird. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-30 17:11:53
|
Hi all,
I've decided on some semantics for how to specify installation paths
using Module::Build. Here's the POD I've written for it, please give
me feedback if you have any.
Thanks.
-Ken
-----------------------------------------------------------
=head2 How Installation Works
When you invoke Module::Build's C<build> action, it needs to figure
out where to install things. The nutshell version of how this works
is that default installation locations are determined from
F<Config.pm>, and they may be overridden by using the C<install_path>
parameter. An C<install_base> parameter lets you specify an
alternative installation root like F</home/foo>, and a C<destdir> lets
you specify a temporary installation directory like F</tmp/install> in
case you want to create bundled-up installable packages.
Natively, Module::Build provides default installation locations for
the following types of installable items:
=over 4
=item lib
Usually pure-Perl module files ending in F<.pm>.
=item arch
"Architecture-dependent" module files, usually produced by compiling
XS, Inline, or similar code.
=item script
Programs written in pure Perl. Try to make these as small as possible
- put the code into modules whenever possible.
=item bin
"Architecture-dependent" programs, i.e. compiled C code or something.
Pretty rare to see this in a perl distribution, but it happens.
=item libdoc
Documentation for the stuff in C<lib> and C<arch>. This is usually
generated from the POD in F<.pm> files. Under Unix, these are manual
pages belonging to the 'man3' category.
=item bindoc
Documentation for the stuff in C<script> and C<bin>. Usually
generated from the POD in those files. Under Unix, these are manual
pages belonging to the 'man1' category.
=back
The default destinations for these installable things come from
entries in your system's C<Config.pm>. You can select from three
different sets of default locations by setting the C<installdirs>
parameter as follows:
'installdirs' set to:
core site vendor
uses the following defaults from Config.pm:
lib => installprivlib installsitelib installvendorlib
arch => installarchlib installsitearch installvendorarch
script => installscript installsitebin installvendorbin
bin => installbin installsitebin installvendorbin
libdoc => installman3dir installsiteman3dir installvendorman3dir
bindoc => installman1dir installsiteman1dir installvendorman1dir
(Note that the 'script' line is different from MakeMaker -
unfortunately there's no such thing as "installsitescript" or
"installvendorscript" entry in C<Config.pm>, so we use the
"installsitebin" and "installvendorbin" entries to at least get the
general location right. In the future, if C<Config.pm> adds some more
appropriate entries, we'll start using those.)
=item 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
=item install_base
You can also set the whole bunch of installation paths by supplying the
C<install_base> parameter to point to a directory on your system. For
instance, if you set C<install_base> to "/home/ken" on a Linux
system, you'll install as follows:
lib => /home/ken/lib
arch => /home/ken/lib/i386-linux
script => /home/ken/scripts
bin => /home/ken/bin
libdoc => /home/ken/man/man1
bindoc => /home/ken/man/man3
Note that this is I<different> from how MakeMaker's C<PREFIX>
parameter works. C<PREFIX> tries to create a mini-replica of a
C<site>-style installation under the directory you specify, which is
not always possible (and the results are not always pretty in this
case). C<install_base> just gives you a default layout under the
directory you specify, which may have little to do with the
C<installdirs=site> layout.
The exact layout under the directory you specify may vary by system -
we try to do the "sensible" thing on each platform.
=item destdir
If you want to install everything into a temporary directory first
(for instance, if you want to create a directory tree that a package
manager like C<rpm> or C<dpkg> could create a package from), you can
use the C<destdir> parameter:
perl Build.PL destdir=/tmp/foo
or
Build install destdir=/tmp/foo
This will effectively install to "$destdir/$sitelib",
"$destdir/$sitearch", and the like, except that it will use
C<File::Spec> to make the pathnames work correctly on whatever
platform you're installing on.
=item uninst
If you want the installation process to look around in C<@INC> for
other versions of the stuff you're installing and try to delete it,
you can use the C<uninst> parameter, which tells C<Module::Install> to
do so:
Build install uninst=1
This can be a good idea, as it helps prevent multiple versions of a
module from being present on your system, which can be a confusing
situation indeed.
=back
|
|
From: <ajs...@ya...> - 2003-06-30 09:07:26
|
Joshua Hoblitt wrote: > But it generates a makefile on win32 that calls Build so you can > still use make, right? So the question is why does 'nmake' succeed > and 'nmake test' fail? This has been fixed in latest CVS. Basically, it was generating a GNU makefile, not a "lowest common denominator" one. See http://sourceforge.net/mailarchive/forum.php?thread_id=2557220&forum_id=10905 for more details. /-\ http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. |
|
From: Joshua H. <jho...@if...> - 2003-06-30 00:18:54
|
> On Sat, 28 Jun 2003, Joshua Hoblitt wrote: > > > I received this bug report on one of my modules. Is this a known > > problem with Module::Build or nmake? > > Module::Build doesn't use make, so instead of "nmake test" you need to do > "./Build test" or ".\Build test". But it generates a makefile on win32 that calls Build so you can still use make, right? So the question is why does 'nmake' succeed and 'nmake test' fail? -J -- |
|
From: Dave R. <au...@ur...> - 2003-06-29 22:44:22
|
On Sat, 28 Jun 2003, Joshua Hoblitt wrote: > I received this bug report on one of my modules. Is this a known > problem with Module::Build or nmake? Module::Build doesn't use make, so instead of "nmake test" you need to do "./Build test" or ".\Build test". -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Joshua H. <jho...@if...> - 2003-06-29 07:38:48
|
Hello, I received this bug report on one of my modules. Is this a known problem with Module::Build or nmake? Cheers, -J -- ---------- Forwarded message ---------- Date: Fri, 27 Jun 2003 10:15:15 -0700 From: "Hill, Ronald" <ron...@pl...> To: 'Joshua Hoblitt' <jho...@if...>, DateTime <dat...@pe...> Subject: RE: yet another DT::F::ISO8601 with yet another version Hi Joshua, > Available immediately from: > > http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO86 > 01-0.02.tar.gz > > I've been busy the last few days so I haven't made much > progress. There is still something wrong with the ISO week > -> DT conversion. 3 tests are coming up 1 week short. I > would really appreciate a heads up if anyone can see the problem. Nice module!! installation works on Win32 systems. I also noticed that nmake test does not work. F:\perl_modules\DateTime-Format-ISO8601-0.02>nmake test Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1073: don't know how to make 'test' Stop. So I had to run perl build test to run the tests. You might want to update the docs on this. Ron Hill |
|
From: Dave R. <au...@ur...> - 2003-06-26 18:26:45
|
On Thu, 26 Jun 2003, Ken Williams wrote: > On Thursday, June 26, 2003, at 12:43 PM, Dave Rolsky wrote: > > > > Savannah's worked just fine. Since all you care about, I assume, is > > mailing lists and CVS, it's basically identical. > > I looked through their services listings, and it doesn't look like we'd > be able to import the CVS repository and maintain history. 'cvs > import' will mess with branches, won't it? I sent them the Params::Validate tarball and they imported it no problem. > > No subversion yet. I'd > > love to see a shared provider for it, though. That'd be sweet. > > Yeah. I'm divided about whether to use it for a project like this one > though, where it might be an obstacle to more people getting involved. The dev version of ViewCVS now supports subversion, and is used by the Subversion developers. It seems to be working well at this point. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-26 18:18:39
|
On Thursday, June 26, 2003, at 12:43 PM, Dave Rolsky wrote: > > Savannah's worked just fine. Since all you care about, I assume, is > mailing lists and CVS, it's basically identical. I looked through their services listings, and it doesn't look like we'd be able to import the CVS repository and maintain history. 'cvs import' will mess with branches, won't it? We probably care about CVS and mailing lists, plus web pages (which savannah has) and file releases (which aren't a big deal but it's handy to have instantly-downloadable tarballs). I don't think savannah has a file release mechanism, at least not that I can find. > No subversion yet. I'd > love to see a shared provider for it, though. That'd be sweet. Yeah. I'm divided about whether to use it for a project like this one though, where it might be an obstacle to more people getting involved. -Ken |
|
From: Dave R. <au...@ur...> - 2003-06-26 17:44:57
|
On Thu, 26 Jun 2003, Ken Williams wrote: > How happy have you been with savannah.nongnu.org? Do they offer the > same kinds of services? Maybe even subversion? Savannah's worked just fine. Since all you care about, I assume, is mailing lists and CVS, it's basically identical. No subversion yet. I'd love to see a shared provider for it, though. That'd be sweet. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-26 17:04:10
|
On Thursday, June 26, 2003, at 12:23 AM, Dave Rolsky wrote: > I'm still not seeing the Cookbook, or the changes to the MANIFEST. > Krap. How happy have you been with savannah.nongnu.org? Do they offer the same kinds of services? Maybe even subversion? -Ken |
|
From: Dave R. <au...@ur...> - 2003-06-26 05:24:52
|
I'm still not seeing the Cookbook, or the changes to the MANIFEST. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-06-25 21:56:53
|
On Wed, 25 Jun 2003, Ken Williams wrote: > > See what I mean? The idea behind M::B is great, but it simply doesn't > > work if you are > > stuck using CPAN.pm and trying to automate things. > > Complete emulation of MakeMaker-style Makefile.PL files would be great. > We're not there yet, though. First we have to support all the things > MakeMaker can do, then we have to provide the translation layer. Also, I sent Andreas a patch a while back to make CPAN.pm support M::B directly. It was against 1.59_54, but I suspect it'd still apply. I think Ken also put it in the Module-Build CVS repository. It doesn't add support for M::B directives, though. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-25 19:58:42
|
On Tuesday, June 24, 2003, at 03:33 PM, James.FitzGibbon wrote:
>
> I love Module::Build. I hate Module::Build. I love the idea, but the
> hassles involved
> in providing a transition from E::MM to it are driving me up the wall.
> Perhaps someone can help.
>
> I'm have a script that will fetch from CPAN and bundle a module into a
> zipfile for
> later deployment on multiple machines. With Makefile.PL based modules
> it works fine, but
> M::B (or M::B::Compat) modules break it.
>
> My bundler script uses CPAN.pm, so I have no choice but to use
> M::B::Compat to tackle this
> problem. Up till now, the basic flow was:
>
> 1. Create a temp dir for installation
> 2. get the module
> 3. Set $CPAN::Config->{makepl_arg} to "PREFIX=$dir SITEPREFIX=$dir"
> 4. make module
> 5. test module
> 6. install module
> 7. zip up contents of $dir.
I think it would be much better to use 'distdir' (or 'DISTDIR' for
MakeMaker) for this. PREFIX and SITEPREFIX are too DWIMmy to really
work reliably, and distdir is created specifically for what you're
doing. Recent versions of MakeMaker support DISTDIR too.
> There is the 'destdir' parameter, but that doesn't do the same thing
> as overriding
> prefix:
>
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (592) > perl Build.PL
> destdir=/tmp/foo
> Deleting _build
> Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
> Checking whether your kit is complete...
> Looks good
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Log-Dispatch' version '2.06'
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (593) > ./Build
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (594) > ./Build fakeinstall
> Installing /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Syslog.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Handle.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Output.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Base.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Screen.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/File.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/ApacheLog.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/
> MailSend.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/
> MIMELite.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/
> MailSender.pm
> Installing
> /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/
> MailSendmail.pm
>
> because it creates an installation hierarchy relative to / instead of
> $Config{installprefix}.
I'd argue that it's better to make it relative to '/'. On my machine
(OS X), $Config{installprivlib} and $Config{installsitelib} and
$Config{installman1dir} don't share any directory components except for
'/' :
installprivlib='/System/Library/Perl'
installsitelib='/Library/Perl'
installman1dir='/usr/share/man/man1'
What would you specify for PREFIX or SITEPREFIX in this case? There
would really be no way to get it to work the way you want. Using
destdir you can get it to work really easily.
So yeah, it's not the same, but it's better. =)
>
> What's worse, M::B::Compat doesn't let me pass M::B directives on the
> command line
> (only E::MM ones), so I can' use the $CPAN::Config->{makepl_arg}
> override:
>
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (637) > perl Makefile.PL
> destdir=/tmp/foo
> Unknown parameter 'destdir' at
> /home_dir/jfitzgi/myperl/lib/perl5/site_perl/5.8.0/Module/Build/
> Compat.pm line 26.
> [appserv:jfitzgi] ~/Log-Dispatch-2.06 (638) >
I'm not sure it makes much sense to allow M::B directives to
Makefile.PL. It's pretending to be a Makefile.PL and emulating its
interface.
It might make sense to just lower-case all unknown parameters and send
them through. That's an easy patch if people agree that it's a good
idea.
--- lib/Module/Build/Compat.pm 11 Jun 2003 14:40:57 -0000 1.25
+++ lib/Module/Build/Compat.pm 25 Jun 2003 19:55:35 -0000
@@ -98,7 +98,8 @@
my $trans = $makefile_to_build{$key};
push @out, ref($trans) ? $trans->($val) : "$trans=$val";
} else {
- warn "Unknown parameter '$key'";
+ warn "Unknown parameter '$key', passing as '", lc($key), "'\n";
+ push @out, "\L$key\E=$val";
}
}
> Nor does CPAN allow me to override the script to call, so I can't have
> it sneakily
> call Build.PL instead. I *must* call Makefile.PL, but I can't use
> destdir and passing
> prefix doesn't work properly.
PREFIX won't ever be supported under M::B if I have anything to say
about it. It's been very headachy under MakeMaker.
>
> See what I mean? The idea behind M::B is great, but it simply doesn't
> work if you are
> stuck using CPAN.pm and trying to automate things.
Complete emulation of MakeMaker-style Makefile.PL files would be great.
We're not there yet, though. First we have to support all the things
MakeMaker can do, then we have to provide the translation layer.
-Ken
|
|
From: James.FitzGibbon <Jam...@ta...> - 2003-06-24 20:38:46
|
I love Module::Build. I hate Module::Build. I love the idea, but the =
hassles involved
in providing a transition from E::MM to it are driving me up the wall.
Perhaps someone can help.
I'm have a script that will fetch from CPAN and bundle a module into a =
zipfile for
later deployment on multiple machines. With Makefile.PL based modules =
it works fine, but
M::B (or M::B::Compat) modules break it.
My bundler script uses CPAN.pm, so I have no choice but to use =
M::B::Compat to tackle this
problem. Up till now, the basic flow was:
1. Create a temp dir for installation
2. get the module
3. Set $CPAN::Config->{makepl_arg} to "PREFIX=3D$dir SITEPREFIX=3D$dir"
4. make module
5. test module
6. install module
7. zip up contents of $dir.
The result of which was an archive that was suitable for extraction =
relative to
$Config{installprefix}:
[app3d03:jfitzgi] ~/modules/5.8.0 (6) > unzip -t =
thread-barrier-0.100.aix4.zip
Archive: thread-barrier-0.100.aix4.zip
testing: man/ OK
testing: man/man3/ OK
testing: man/man3/Thread::Barrier.3 OK
testing: lib/ OK
testing: lib/perl5/ OK
testing: lib/perl5/5.8.0/ OK
testing: lib/perl5/5.8.0/aix-thread-multi/ OK
testing: lib/perl5/site_perl/ OK
testing: lib/perl5/site_perl/5.8.0/ OK
testing: lib/perl5/site_perl/5.8.0/Thread/ OK
testing: lib/perl5/site_perl/5.8.0/Thread/Barrier.pm OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/ OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/ OK
testing: lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/ =
OK
testing: =
lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/Barrier/ OK
testing: =
lib/perl5/site_perl/5.8.0/aix-thread-multi/auto/Thread/Barrier/.packlist =
OK
No errors detected in compressed data of thread-barrier-0.100.aix4.zip.
[app3d03:jfitzgi] ~/modules/5.8.0 (7) >
Recently, Dave Rolsky updated Log::Dispatch to use M::B. When I try to =
use the bundler
on that, it completely ignores the M::B::Compat translated =
"prefix=3D$dir siteprefix=3D$dir" directives:
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (552) > perl Makefile.PL =
PREFIX=3D/tmp/foo SITEPREFIX=3D/tmp/foo
perl Build.PL prefix=3D/tmp/foo siteprefix=3D/tmp/foo
Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
Checking whether your kit is complete...
Looks good
Creating new 'Build' script for 'Log-Dispatch' version '2.06'
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (553) > make
./Build
lib/Log/Dispatch.pm -> blib/lib/Log/Dispatch.pm
lib/Log/Dispatch/Syslog.pm -> blib/lib/Log/Dispatch/Syslog.pm
lib/Log/Dispatch/Handle.pm -> blib/lib/Log/Dispatch/Handle.pm
lib/Log/Dispatch/Output.pm -> blib/lib/Log/Dispatch/Output.pm
lib/Log/Dispatch/Email.pm -> blib/lib/Log/Dispatch/Email.pm
lib/Log/Dispatch/Base.pm -> blib/lib/Log/Dispatch/Base.pm
lib/Log/Dispatch/Screen.pm -> blib/lib/Log/Dispatch/Screen.pm
lib/Log/Dispatch/File.pm -> blib/lib/Log/Dispatch/File.pm
lib/Log/Dispatch/ApacheLog.pm -> blib/lib/Log/Dispatch/ApacheLog.pm
lib/Log/Dispatch/Email/MailSend.pm -> =
blib/lib/Log/Dispatch/Email/MailSend.pm
lib/Log/Dispatch/Email/MIMELite.pm -> =
blib/lib/Log/Dispatch/Email/MIMELite.pm
lib/Log/Dispatch/Email/MailSender.pm -> =
blib/lib/Log/Dispatch/Email/MailSender.pm
lib/Log/Dispatch/Email/MailSendmail.pm -> =
blib/lib/Log/Dispatch/Email/MailSendmail.pm
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (554) > make install
./Build install
Warning: You do not have permissions to install into =
/opt/3d/lib/perl5/site_perl/5.8.0 at =
/opt/3d/lib/perl5/5.8.0/ExtUtils/Install.pm line 84.
mkdir /opt/3d/lib/perl5/site_perl/5.8.0/Log: The file access permissions =
do not allow the specified action. at =
/opt/3d/lib/perl5/5.8.0/ExtUtils/Install.pm line 137
gmake: *** [install] Error 255
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (555) >
There is the 'destdir' parameter, but that doesn't do the same thing as =
overriding
prefix:
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (592) > perl Build.PL =
destdir=3D/tmp/foo
Deleting _build
Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Log-Dispatch' version '2.06'
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (593) > ./Build
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (594) > ./Build fakeinstall
Installing /tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Syslog.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Handle.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Output.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Base.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Screen.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/File.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/ApacheLog.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/MailSend.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/MIMELite.pm
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/MailSender.p=
m
Installing =
/tmp/foo/opt/3d/lib/perl5/site_perl/5.8.0/Log/Dispatch/Email/MailSendmail=
.pm
because it creates an installation hierarchy relative to / instead of =
$Config{installprefix}.
What's worse, M::B::Compat doesn't let me pass M::B directives on the =
command line
(only E::MM ones), so I can' use the $CPAN::Config->{makepl_arg} =
override:
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (637) > perl Makefile.PL =
destdir=3D/tmp/foo
Unknown parameter 'destdir' at =
/home_dir/jfitzgi/myperl/lib/perl5/site_perl/5.8.0/Module/Build/Compat.pm=
line 26.
[appserv:jfitzgi] ~/Log-Dispatch-2.06 (638) >
Nor does CPAN allow me to override the script to call, so I can't have =
it sneakily
call Build.PL instead. I *must* call Makefile.PL, but I can't use =
destdir and passing
prefix doesn't work properly.
See what I mean? The idea behind M::B is great, but it simply doesn't =
work if you are
stuck using CPAN.pm and trying to automate things.
Any thoughts?
Thanks.
--
j.
James FitzGibbon =20
Consultant, Ajilon Services, TTS-3D@CC-950=20
jam...@ta...
voice/fax 612-304-6121/3277
|
|
From: Uri G. <ur...@st...> - 2003-06-23 21:22:14
|
ken, any info on my manifest filter tools idea? just to reiterate (as i am sure you have lost most of your yapc memories :), i want some util subs and command line options to filter and do actions on files in the manifest. here are some simple use cases: 1. run (internal) grep on all pm (or any globbed recursively) files: build grep '*.pm' 2. run a line counter script on all source files: build line_count 'bin/* *.pm' the command line would have a first arg of a build builtin (a supported set) OR an external executable. the second arg (maybe a perl regex instead of a glob) is used to filter the manifest. all matching filename/paths will be passed to the command. just an itch i have and it would make me switch over to build much faster. i use those types of file operations and i have to hand code them now as make blows here. i want them to only work on files in the manifest so you can have work or temp files that are not found. thanx, uri -- Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org |
|
From: Dave R. <au...@ur...> - 2003-06-23 17:22:56
|
On Mon, 23 Jun 2003, Ken Williams wrote: > sf.net was down for a while, I couldn't check it in until about 10 > minutes after I sent that message. It's still not showing up. I just noticed that the web version says that it's on the backup CVS server, and may be up to 24 hours old. I wonder if the same goes for anon CVS? But you did commit, not just add? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-23 17:08:03
|
On Monday, June 23, 2003, at 12:04 PM, Dave Rolsky wrote: > On Mon, 23 Jun 2003, Ken Williams wrote: > >> I've added a lib/Module/Build/Cookbook.pm to CVS. It's got a few >> examples there already, let me know if you have something you'd like >> to >> add. > > Are you sure you checked it in? I can't see it. sf.net was down for a while, I couldn't check it in until about 10 minutes after I sent that message. -Ken |
|
From: Dave R. <au...@ur...> - 2003-06-23 17:05:24
|
On Mon, 23 Jun 2003, Ken Williams wrote: > I've added a lib/Module/Build/Cookbook.pm to CVS. It's got a few > examples there already, let me know if you have something you'd like to > add. Are you sure you checked it in? I can't see it. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-06-23 16:35:27
|
On Mon, 23 Jun 2003, Ken Williams wrote: > I'm probably open to the idea, but not for the 1.19 release. I sort of > also need to be convinced that it's worthwhile putting these things on > CPAN, since I'd imagine they will mostly be special-purpose tools for > specific build processes. I can definitely see a module that would be used for installing Mason components, or HTML docs, and so on. When you start thinking of Module::Build as an _app_ installer, I think you can start seeing the potential for wanting to share various types of installation code. For example, how about some interactive code that works with App::Info to install mod_perl and Apache, or use an existing one? Certainly that could be useful for many applications. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-06-23 16:27:40
|
On Friday, June 20, 2003, at 11:31 PM, Dave Rolsky wrote: > I believe it was Mark Fowler who brought this issue up at the M::B BOF > at > YAPC. > > His basic problem was that he had a subclass of M::B that he wanted to > use > in various modules he might distribute on CPAN. This leads to the > question of how to specify this prerequisite. > > I think this needs a new prereq specification for "bootstrap" modules, > so > we can do something like this: > > use Module::Build; > Module::Build->boostrap_requires( 'Module::Build::Foo' => 0.15, ... > ); > > require Module::Build::Foo; > > Module::Build::Foo->new( ... )->create_build_script; > > This wouldn't be too hard to implement but I wanted to discuss the API > before creating a patch. > > So what do others think? I'm probably open to the idea, but not for the 1.19 release. I sort of also need to be convinced that it's worthwhile putting these things on CPAN, since I'd imagine they will mostly be special-purpose tools for specific build processes. -Ken |
|
From: Ken W. <ke...@ma...> - 2003-06-23 16:22:18
|
I've applied the first one. I'm working kind of slowly at the moment and I'll get to the other two soon. Thanks. -Ken On Friday, June 20, 2003, at 11:46 PM, Dave Rolsky wrote: > The patch below my sig does three things: > > 1. Fix MANIFEST to include INSTALL.txt, not INSTALL > > 2. Make the distsign action depend on distdir unless $self->dist_dir > already exists. Otherwise the sequence of "perl Build.PL", "./Build > distsign" fails, which is almost certainly a bug. > > 3. Adds a verify action which verifies a signature. > > > -dave > > /*======================= > House Absolute Consulting > www.houseabsolute.com > =======================*/ > > ? t/Sample/SIGNATURE > ? t/Sample/Sample-0.01.tar.gz > Index: MANIFEST > =================================================================== > RCS file: /cvsroot/module-build/Module-Build/MANIFEST,v > retrieving revision 1.18 > diff -u -r1.18 MANIFEST > --- MANIFEST 22 May 2003 17:19:04 -0000 1.18 > +++ MANIFEST 21 Jun 2003 04:44:11 -0000 > @@ -1,6 +1,6 @@ > Build.PL > Changes > -INSTALL > +INSTALL.txt > MANIFEST > META.yml > Makefile.PL > Index: lib/Module/Build.pm > =================================================================== > RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build.pm,v > retrieving revision 1.76 > diff -u -r1.76 Build.pm > --- lib/Module/Build.pm 17 Jun 2003 06:19:13 -0000 1.76 > +++ lib/Module/Build.pm 21 Jun 2003 04:44:11 -0000 > @@ -141,8 +141,8 @@ > distclean skipcheck > distdir test > distsign testdb > - disttest versioninstall > - fakeinstall > + disttest verify > + fakeinstall versioninstall > > You can run the 'help' action for a complete list of actions. > > @@ -877,6 +877,10 @@ > > This is a synonym for the 'test' action with the C<debugger=1> > argument. > + > +=item verify > + > +Verifies the signatures found in the distribution's SIGNATURE file. > > =item clean > > Index: lib/Module/Build/Base.pm > =================================================================== > RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v > retrieving revision 1.129 > diff -u -r1.129 Base.pm > --- lib/Module/Build/Base.pm 17 Jun 2003 19:19:21 -0000 1.129 > +++ lib/Module/Build/Base.pm 21 Jun 2003 04:44:16 -0000 > @@ -819,6 +819,23 @@ > return [sort @tests]; > } > > +sub ACTION_verify { > + my ($self) = @_; > + > + $self->_load_module_signature('verify') or return; > + > + # We protect the verify with an eval{} to make sure we get back to > + # the right directory after a signature failure. > + > + chdir $self->dist_dir or die "Can't chdir() to " . $self->dist_dir > . ": $!"; > + my $ok = eval {Module::Signature::verify() == > Module::Signature::SIGNATURE_OK()}; > + my @err = $@ ? ($@) : (); > + chdir $self->base_dir or push @err, "Can't chdir() back to " . > $self->base_dir . ": $!"; > + die join "\n", @err if @err; > + > + print "Signature is", ($ok ? "" : " not"), " valid\n"; > +} > + > sub ACTION_testdb { > my ($self) = @_; > local $self->{properties}{debugger} = 1; > @@ -1144,11 +1161,10 @@ > > sub ACTION_distsign { > my ($self) = @_; > - > - unless (eval { require Module::Signature; 1 }) { > - warn "Couldn't load Module::Signature for 'distsign' action:\n > $@\n"; > - return; > - } > + > + $self->_load_module_signature('distsign') or return; > + > + $self->depends_on('distdir') unless -d $self->dist_dir; > > # We protect the signing with an eval{} to make sure we get back to > # the right directory after a signature failure. > @@ -1160,7 +1176,16 @@ > die join "\n", @err if @err; > } > > +sub _load_module_signature { > + my ($self, $action) = @_; > > + unless (eval { require Module::Signature; 1 }) { > + warn "Couldn't load Module::Signature for '$action' action:\n > $@\n"; > + return; > + } > + > + return 1; > +} > > sub ACTION_skipcheck { > my ($self) = @_; |
|
From: Ken W. <ke...@ma...> - 2003-06-23 16:00:36
|
Hey, I've added a lib/Module/Build/Cookbook.pm to CVS. It's got a few examples there already, let me know if you have something you'd like to add. -Ken |
7 messages has been excluded from this view by a project administrator.
