module-build-general Mailing List for Module::Build (Page 165)
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: Ken W. <ke...@ma...> - 2003-07-03 19:49:16
|
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. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-03 19:27:37
|
On Thu, 3 Jul 2003, Ken Williams wrote: > > On Thu, 3 Jul 2003, Ken Williams wrote: > > > >>> 3. Adds a verify action which verifies a signature. > >> > >> Why does this patch (excerpt below) verify in $self->dist_dir? Seems > >> like we'd want to verify in the main directory, $self->base_dir. > > > > Hmm, that's a good question. For the module _author_, verifying > > should be > > done in the dist dir, because that's what contains _exactly_ what will > > be > > in the final distro. > > Probably this should just be done automatically after signing, to make > sure that the signature just created is actually valid. Or one could > just assume it's valid. > > > > For the installer, verify should be run in the > > base_dir, I guess. Except, I bet it'll fail because of the presence of > > the "Build" script. > > Extra files will make it fail? 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. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-03 19:15:36
|
On Thursday, July 3, 2003, at 12:56 PM, Dave Rolsky wrote: > On Thu, 3 Jul 2003, Ken Williams wrote: > >>> 3. Adds a verify action which verifies a signature. >> >> Why does this patch (excerpt below) verify in $self->dist_dir? Seems >> like we'd want to verify in the main directory, $self->base_dir. > > Hmm, that's a good question. For the module _author_, verifying > should be > done in the dist dir, because that's what contains _exactly_ what will > be > in the final distro. Probably this should just be done automatically after signing, to make sure that the signature just created is actually valid. Or one could just assume it's valid. > For the installer, verify should be run in the > base_dir, I guess. Except, I bet it'll fail because of the presence of > the "Build" script. Extra files will make it fail? -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-03 17:58:58
|
On Thu, 3 Jul 2003, Ken Williams wrote: > > 3. Adds a verify action which verifies a signature. > > Why does this patch (excerpt below) verify in $self->dist_dir? Seems > like we'd want to verify in the main directory, $self->base_dir. Hmm, that's a good question. For the module _author_, verifying should be done in the dist dir, because that's what contains _exactly_ what will be in the final distro. For the installer, verify should be run in the base_dir, I guess. Except, I bet it'll fail because of the presence of the "Build" script. Hmm, I wonder how to handle that. Autrijus? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-03 17:53:59
|
On Thursday, July 3, 2003, at 12:49 PM, Andy Dougherty wrote:
> On Thu, 3 Jul 2003, Ken Williams wrote:
>
>> (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.)
>
> That sounds like a good plan. Those entries should appear in 5.8.1's
> Config.pm, when that is released.
Oh, good. That means I don't have to do the lobbying/convincing that I
thought I was going to have to do. =)
The code in the soon-to-be-released version of Module::Build looks like
this:
core => {
lib => $c->{installprivlib},
arch => $c->{installarchlib},
bin => $c->{installbin},
script => $c->{installscript},
bindoc => $c->{installman1dir},
libdoc => $c->{installman3dir},
},
site => {
lib => $c->{installsitelib},
arch => $c->{installsitearch},
bin => $c->{installsitebin},
script => $c->{installsitescript} ||
$c->{installsitebin},
bindoc => $c->{installsiteman1dir},
libdoc => $c->{installsiteman3dir},
},
vendor => {
lib => $c->{installvendorlib},
arch => $c->{installvendorarch},
bin => $c->{installvendorbin},
script => $c->{installvendorscript} ||
$c->{installvendorbin},
bindoc => $c->{installvendorman1dir},
libdoc => $c->{installvendorman3dir},
},
where $c is a reference to %Config. So it should just start working if
the %Config entries appear.
Thanks for the status update.
-Ken
|
|
From: Andy D. <dou...@la...> - 2003-07-03 17:49:28
|
On Thu, 3 Jul 2003, Ken Williams wrote:
>
> On Thursday, July 3, 2003, at 08:24 AM, Abigail wrote:
>
> >> 'installdirs' set to:
> >> core site vendor
> >>
> >> bin => installbin installsitebin installvendorbin
> >> script => installscript installscript installscript
> > Is the row for 'script' a typo, or are indeed all scripts, whether
> > they are core, site and vendor always placed in the same directory?
>
> Unfortunately it wasn't a typo. That's the way MakeMaker does it too,
> because there's no such thing as 'installsitescript' or
> 'installvendorscript' in Config.pm.
Well, there were supposed to be, and they are even documented in 5.6.1's
INSTALL file, but due to a variety of oversights, the actual code to set
them didn't make it into either 5.6.1 or 5.8.0, though it is now in
5.8.1-to-be.
> (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.)
That sounds like a good plan. Those entries should appear in 5.8.1's
Config.pm, when that is released.
--
Andy Dougherty dou...@la...
|
|
From: Ken W. <ke...@ma...> - 2003-07-03 17:48:37
|
On Friday, June 20, 2003, at 11:46 PM, Dave Rolsky wrote:
>
> 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.
I've applied this fix in a modified form, by increasing the method
granularity. There's now a _sign_dir($dir) method that will do the
signing, and it's invoked by both ACTION_distdir() and
ACTION_distsign(). Still a little clunky, but at least it'll work
correctly in more cases.
>
> 3. Adds a verify action which verifies a signature.
Why does this patch (excerpt below) verify in $self->dist_dir? Seems
like we'd want to verify in the main directory, $self->base_dir.
-Ken
>
> +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";
> +}
> +
|
|
From: Dave R. <au...@ur...> - 2003-07-03 16:31:41
|
Finally. Sheesh, what a PITA. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-07-03 16:30:48
|
No docs for "Build ppd" action. I'd swear I included this with my patch. verify action? This seems pretty straightforward. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-07-03 16:24:10
|
Hi Jim,
Thanks for this report. I hadn't considered dependencies like this
before, but you have a very valid point. Unfortunately I'm not yet
sure how to solve it well!
It may be that we could add a 'perl-config' item, which could check
certain values in Config.pm. Then you could check 'usethreads' (or
more likely, 'useithreads'), 'usemultiplicity', or whatever.
I think this is going to have to wait until after 0.19 is released
though, because it's way overdue and there are way too many feature
changes in it already. I'll be happy to revisit it then, especially if
you remind me.
Until then, the best way to express this dependency might be to
override the check_prereq() method like so:
sub check_prereq {
my $self = shift;
die "Perl must be built with 'useithreads' defined in order to
install this module"
unless $self->{config}{useithreads};
return $self->SUPER::check_prereq();
}
-Ken
(Aside: why won't Hook::Scope install on non-threaded perls?)
On Monday, June 30, 2003, at 03:37 PM, Jim Cromie wrote:
>
> Folks,
>
> while trying to install Hook::Scope on a non-threaded perl, I
> discovered
> that it is unsupported on on-threaded builds.
>
> now, Hook::Scope uses an old-style Makefile.PL, but Id much rather
> rewrite it into a Build.PL than try to shoehorn a custom dependency
> check
> into its Makefile.PL (tho if its obvious to you, please let me, or
> ABERGMAN know)
>
> Anyway, such a dependency is on perl itself, which in my case is
> already used
>
> requires => {
> perl => '5.8.0',
> B::Generate => 0,
> optimizer => 0,
> },
>
> Is it possible/reasonable to add 2 dependencies on perl, something like
>
> requires => {
> perl => [ '5.8.0', qr/thread-multi/ ],
> B::Generate => 0,
> optimizer => 0,
> },
>
>
> I tried this, it bombs currently:
> Invalid prerequisite condition 'ARRAY(0x8111eb4)' for perl at
> /usr/local/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm line 436.
>
> This expression of a dependency on a threaded install is somewhat
> problematic,
> as its not depending upon a particular package, but on a component in
> @INC.
> But a dependency on threads is no good, cuz threads is specifically
> available
> as a no-op under non-threaded builds.
>
> ARRAY is also not kosher, so I tried following - also failed:
>
> requires => {
> perl => '5.8.0, thread-multi',
> B::Generate => 0,
> optimizer => 0,
> }
>
> This still has problem of implied check on @INC, but it fails before
> that, on 5.8.0
>
> Invalid prerequisite condition '5.8.0' for perl at
> /usr/local/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm line 436.
>
>
> Lastly, I tried this - but it fails with same error as above
>
> requires => {
> perl => 'grep {/thread-multi/} @INC',
> B::Generate => 0,
> optimizer => 0,
> },
>
>
> So - what would be a good approach ?
> what could evolve into an acceptable patch ?
>
> please cc me, as im not currently on the mailing list.
>
> tia,
> -jimc
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/
> 01
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-07-03 15:11:40
|
On Thursday, July 3, 2003, at 08:24 AM, Abigail wrote:
> On Wed, May 14, 2003 at 12:14:02PM -0500, Ken Williams wrote:
>>
>> This means we can let people specify a family of defaults using an
>> "installdirs" parameter set to one of three options:
>>
>> 'installdirs' set to:
>> core site vendor
>>
>> results in the following defaults from Config.pm:
>>
>> arch => installarchlib installsitearch
>> installvendorarch
>> lib => installprivlib installsitelib installvendorlib
>> bin => installbin installsitebin installvendorbin
>> script => installscript installscript installscript
>> man1 => installman1dir installsiteman1dir
>> installvendorman1dir
>> man3 => installman3dir installsiteman3dir
>> installvendorman3dir
>
>
> Is the row for 'script' a typo, or are indeed all scripts, whether
> they are core, site and vendor always placed in the same directory?
Unfortunately it wasn't a typo. That's the way MakeMaker does it too,
because there's no such thing as 'installsitescript' or
'installvendorscript' in Config.pm.
However, I've since decided that this is unacceptable, since it really
does get in the way of sane layout management. It's also responsible
for the problem of LWP's /usr/bin/HEAD overwriting /usr/bin/head on Mac
OS X.
So in recent Module::Build betas, I've changed to this:
------------------------------------------------------------------
=head3 installdirs
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
The default value of C<installdirs> is "site". If you're creating
vendor distributions of module packages, you may want to do something
like this:
perl Build.PL installdirs=vendor
or
Build install installdirs=vendor
If you're installing an updated version of a module that was included
with perl itself (i.e. a "core module"), then you may set
C<installdirs> to "core" to overwrite the module in its present
location.
(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.)
------------------------------------------------------------------
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-07-03 15:06:58
|
On Thursday, July 3, 2003, at 04:13 AM, Andrew Savige wrote: > > For the record, with the new "lowest common denominator" makefile > changes, the original name INSTALL should now work fine on all > platforms and with all makes, case sensitive or not. Up to you > whether you want to change the name back again. Hmm, maybe I should change it back. I noticed that search.cpan.org doesn't pick up INSTALL.txt as a 'special file', but it does pick up INSTALL. > Also for the record, I am not a Savage, but I think I am starting > to like the way you spelt my name. No, really I am. Reminds of the > famous Florida wrestler "Macho Man" Randy Savage: > http://www.geocities.com/TelevisionCity/Station/7480/machobio.html Heh - all the same, I should probably spell it correctly. :-) > Hurrah, 0.18_03 passed all tests on Windows -- the first of the 0.18 > series to do that for me. :-) However, I have not tested with > Module::Signature yet (I have found it quite a trial to get > Module::Signature to fly on Windows). Great news! As you noticed, I disabled the Module::Signature test by default unless the user sets an environment variable, because support for it is still flaky. -Ken |
|
From: Abigail <ab...@ab...> - 2003-07-03 13:25:16
|
On Wed, May 14, 2003 at 12:14:02PM -0500, Ken Williams wrote: > > This means we can let people specify a family of defaults using an > "installdirs" parameter set to one of three options: > > 'installdirs' set to: > core site vendor > > results in the following defaults from Config.pm: > > arch => installarchlib installsitearch installvendorarch > lib => installprivlib installsitelib installvendorlib > bin => installbin installsitebin installvendorbin > script => installscript installscript installscript > man1 => installman1dir installsiteman1dir > installvendorman1dir > man3 => installman3dir installsiteman3dir > installvendorman3dir Is the row for 'script' a typo, or are indeed all scripts, whether they are core, site and vendor always placed in the same directory? Abigail |
|
From: <ajs...@ya...> - 2003-07-03 09:13:25
|
Ken Williams <ke...@ma...> wrote: > http://search.cpan.org/author/KWILLIAMS/Module-Build-0.18_03/ > 0.18_03 > > - 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 Savage] For the record, with the new "lowest common denominator" makefile changes, the original name INSTALL should now work fine on all platforms and with all makes, case sensitive or not. Up to you whether you want to change the name back again. Also for the record, I am not a Savage, but I think I am starting to like the way you spelt my name. No, really I am. Reminds of the famous Florida wrestler "Macho Man" Randy Savage: http://www.geocities.com/TelevisionCity/Station/7480/machobio.html Hurrah, 0.18_03 passed all tests on Windows -- the first of the 0.18 series to do that for me. :-) However, I have not tested with Module::Signature yet (I have found it quite a trial to get Module::Signature to fly on Windows). /-\ http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile. |
|
From: Ken W. <ke...@ma...> - 2003-07-01 20:13:13
|
Hey, In part because the anonymous CVS access doesn't seem to be working at sourceforge, and in part because I've now implemented support for the 'install_path' parameter (allowing customization of installation paths - and it was basically a one-line patch! Who knew!), I just uploaded a new beta to CPAN and sourceforge: http://search.cpan.org/author/KWILLIAMS/Module-Build-0.18_03/ (will take a couple days) http://sourceforge.net/project/showfiles.php?group_id=45731 (available now) The changes since version 0.18_02 are below. -Ken 0.18_03 - 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. - 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. - 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. - 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 Savage] - Module::Build->known_actions() now works as a class method. - We now use the correct perl interpreter (via Module::Build->find_perl_interpreter) in pass-through makefiles. - 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 Savage] - 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. |
|
From: Ken W. <ke...@ma...> - 2003-07-01 19:50:01
|
On Tuesday, July 1, 2003, at 12:21 PM, Dave Rolsky wrote: > This should be upped to 1.00, since 0.23 is pretty broken on Win32 (no > create_archive method, for one). As of version 1.00, the same code > works > on Win32 and real OS's as well. Done. -Ken |
|
From: Dave R. <au...@ur...> - 2003-07-01 17:22:31
|
This should be upped to 1.00, since 0.23 is pretty broken on Win32 (no create_archive method, for one). As of version 1.00, the same code works on Win32 and real OS's as well. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Mathieu A. <m...@ab...> - 2003-07-01 13:14:32
|
+-le 01/07/2003 07:40 -0500, Ken Williams =E9crivait : |=20 | On Tuesday, July 1, 2003, at 04:06 AM, Mathieu Arnold wrote: |=20 |> Hi, |>=20 |> I use FreeBSD, and I have a lot of perl ports. I needed a module which =20 |> used |> Module::Build to build, and I was displeased to see that I could not |> override PREFIX easily. We usually do this : |> make install PREFIX=3D/something |> so that instead of going into /usr/local/lib/perl5/site_perl/<perl |> version>/, it goes into /something/lib/perl5/site_perl/<perl version>/ |> It's a really important feature for the FreeBSD ports, and believe you |> should know your module well enough to correct this :) |>=20 |=20 | Hi Mathieu, |=20 | Thanks for your message. You probably actually want to use the 'destdir' | parameter, which was created specifically to aid package managers. | Recent versions of MakeMaker have a DESTDIR parameter now too, which does | basically the same thing as in Module::Build. |=20 | Aside from that, the directory customization in released version of | Module::Build is not very good. It's the top priority for version 0.19, | and it's coming along well. You can see the current direction at | = http://sourceforge.net/mailarchive/forum.php?thread_id=3D2686103&forum_id=3D= 1 | 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 add another hack. --=20 Mathieu Arnold |
|
From: Ken W. <ke...@ma...> - 2003-07-01 12:40:50
|
On Tuesday, July 1, 2003, at 04:06 AM, Mathieu Arnold wrote:
> Hi,
>
> I use FreeBSD, and I have a lot of perl ports. I needed a module which
> used
> Module::Build to build, and I was displeased to see that I could not
> override PREFIX easily. We usually do this :
> make install PREFIX=/something
> so that instead of going into /usr/local/lib/perl5/site_perl/<perl
> version>/, it goes into /something/lib/perl5/site_perl/<perl version>/
> It's a really important feature for the FreeBSD ports, and believe you
> should know your module well enough to correct this :)
>
Hi Mathieu,
Thanks for your message. You probably actually want to use the
'destdir' parameter, which was created specifically to aid package
managers. Recent versions of MakeMaker have a DESTDIR parameter now
too, which 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
0.19, and it's coming along well. You can see the current direction at
http://sourceforge.net/mailarchive/
forum.php?thread_id=2686103&forum_id=10905 .
Thanks.
-Ken
|
|
From: Jim C. <jc...@di...> - 2003-07-01 00:39:15
|
Folks,
while trying to install Hook::Scope on a non-threaded perl, I discovered
that it is unsupported on on-threaded builds.
now, Hook::Scope uses an old-style Makefile.PL, but Id much rather
rewrite it into a Build.PL than try to shoehorn a custom dependency check
into its Makefile.PL (tho if its obvious to you, please let me, or
ABERGMAN know)
Anyway, such a dependency is on perl itself, which in my case is already
used
requires => {
perl => '5.8.0',
B::Generate => 0,
optimizer => 0,
},
Is it possible/reasonable to add 2 dependencies on perl, something like
requires => {
perl => [ '5.8.0', qr/thread-multi/ ],
B::Generate => 0,
optimizer => 0,
},
I tried this, it bombs currently:
Invalid prerequisite condition 'ARRAY(0x8111eb4)' for perl at
/usr/local/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm line 436.
This expression of a dependency on a threaded install is somewhat
problematic,
as its not depending upon a particular package, but on a component in @INC.
But a dependency on threads is no good, cuz threads is specifically
available
as a no-op under non-threaded builds.
ARRAY is also not kosher, so I tried following - also failed:
requires => {
perl => '5.8.0, thread-multi',
B::Generate => 0,
optimizer => 0,
}
This still has problem of implied check on @INC, but it fails before
that, on 5.8.0
Invalid prerequisite condition '5.8.0' for perl at
/usr/local/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm line 436.
Lastly, I tried this - but it fails with same error as above
requires => {
perl => 'grep {/thread-multi/} @INC',
B::Generate => 0,
optimizer => 0,
},
So - what would be a good approach ?
what could evolve into an acceptable patch ?
please cc me, as im not currently on the mailing list.
tia,
-jimc
|
|
From: Ken W. <ke...@ma...> - 2003-06-30 22:25:02
|
On Monday, June 30, 2003, at 12:21 PM, Dave Rolsky wrote:
> 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.
I'm totally positive:
% cat CVS/Root
:ext:kwi...@cv...:/cvsroot/module-build
% cvs status lib/Module/Build/Base.pm
===================================================================
File: Base.pm Status: Up-to-date
Working revision: 1.134
Repository revision: 1.134
/cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
When I log in to shell.sourceforge.net, I see the following:
----------------------
On 2003-06-13, changes were made to ViewCVS access and pserver CVS
access.
pserver-based CVS access from this host (the project shell server) will
not
be changed. pserver-based CVS access from other hosts and ViewCVS
access
will now work against data on the backup CVS server (this is a
transparent
change and does not require any configuration changes on your part), as
to
reduce load on the primary CVS server and improve the performance of
developer CVS access. Data on the backup CVS server is roughly 24 hours
old, between sync runs. This change is temporary and is expected to be
reverted in August. See the Site Status page on SourceForge.net for
details.
----------------------
It looks like the peserver access to the repository is stuck around
June 20, because version 1.129 is the last version of Build/Base.pm I
see there. What a pain in the ass!
-Ken
|
|
From: Ken W. <ke...@ma...> - 2003-06-30 20:15:23
|
On Monday, June 30, 2003, at 02:52 PM, Uri Guttman wrote: >>>>>> "KW" == Ken Williams <ke...@ma...> writes: > KW> Yup, it's an editorial. I don't feel bad about editorializing > here, > KW> but I should maybe make it more clear - "in order to promote > reuse" or > KW> something. > > better but i would drop the editorial. So noted. =) > > ahh, hen make it clearer that these are standalone binary exectuables. > Done. > KW> Maybe I should rename this section to "How installation paths are > KW> determined" or something. > > good idea. Done. > i would still show a couple of one line examples at the top so the > reader gets a feel of what the rest of the doc means. i didn't know > where i would put those params until i saw those two lines. and a one > line example for each section would be good too. More examples on the way. There's also a new Module::Build::Cookbook that I started creating at YAPC. -Ken |
|
From: Uri G. <ur...@st...> - 2003-06-30 20:10:22
|
>>>>> "KW" == Ken Williams <ke...@ma...> writes: KW> On Monday, June 30, 2003, at 02:14 PM, Uri Guttman wrote: >>>>>>> "KW" == Ken Williams <ke...@ma...> writes: KW> Yup, it's an editorial. I don't feel bad about editorializing here, KW> but I should maybe make it more clear - "in order to promote reuse" or KW> something. better but i would drop the editorial. 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. >> KW> This isn't XS code. It's binary executables, not binary libraries. KW> That's pretty rare as far as I've seen. ahh, hen make it clearer that these are standalone binary exectuables. KW> Maybe I should rename this section to "How installation paths are KW> determined" or something. good idea. 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. KW> That's because this is just an excerpt from the much larger pod in KW> Module/Build.pm . i would still show a couple of one line examples at the top so the reader gets a feel of what the rest of the doc means. i didn't know where i would put those params until i saw those two lines. and a one line example for each section would be good too. 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: Ken W. <ke...@ma...> - 2003-06-30 19:37:16
|
On Monday, June 30, 2003, at 02:14 PM, Uri Guttman wrote: >>>>>> "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. Yup, it's an editorial. I don't feel bad about editorializing here, but I should maybe make it more clear - "in order to promote reuse" or something. > > 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. This isn't XS code. It's binary executables, not binary libraries. That's pretty rare as far as I've seen. > also what > compiler will be chosen for that? i didn't see any override options in > this doc. Yeah, the compiler all comes from Config.pm , and any Config.pm entry can be overridden. The docs for that are elsewhere. Maybe I should rename this section to "How installation paths are determined" or something. > > 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. You'd probably just subclass Module::Build for that. > 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. :) Yeah, you're right. I also need to say that 'site' is the default. > 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. That's because this is just an excerpt from the much larger pod in Module/Build.pm . > overall, i like it a lot. it is the best high level picture of build.pl > i have seen so far. Thanks. -Ken |
|
From: Dave R. <au...@ur...> - 2003-06-30 19:28:15
|
On Mon, 30 Jun 2003, Uri Guttman wrote: > 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. He means that compiling binary _executable_ is a rarity in Perl module distros, as opposed to compiled modules. > 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. Module::Build is very flexible, so doing extra stuff is always possible at each stage of the build/test/install process (as well as during distro generation, etc.) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
7 messages has been excluded from this view by a project administrator.
