module-build-general Mailing List for Module::Build (Page 143)
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-12-24 02:50:03
|
On 12/21/2003 12:33 PM, Ken Williams wrote: > Hey list, > > van...@pa... tells me, via > https://rt.cpan.org/Ticket/Display.html?id=4615 , that the pass-through > Makefile is broken when using DMake (never heard of it) on Windows > (never heard of it!). I've checked in the following change, anyone see > a problem with it? This works with dmake, nmake and gnu make. Randy. |
|
From: Nicholas C. <ni...@cc...> - 2003-12-22 20:45:35
|
On Mon, Dec 22, 2003 at 01:46:55PM -0600, Ken Williams wrote: > But another thing is that everyone I talk to who's used it seems to > like it, which is probably worth a lot. It is nice. The two things I know that it can't do are 1: If you create a file as part of one submit, and then change it as part of a subsequent submit, you can't integrate both "changes" onto another branch as part of a single submit. I've been bitten by this twice in the past 3 months - it's a strange deficiency. 2: You can't back out an integration. There's a FAQ item about how to do it - ie kludge it. (p4 edit the relevant files, get the (forwards) diff, patch -R, submit) This sucks, because it's as if you did a local edit in that branch, which means you can't (re)integrate the change, and any subsequent changes to that area of code will become conflicts between the two branches. Obviously these two are irritating if you're trying to merge changes over from perl 5.9.x to perl 5.8.x Nicholas Clark |
|
From: Nicholas C. <ni...@cc...> - 2003-12-22 20:23:11
|
On Mon, Dec 22, 2003 at 10:23:15AM +0100, Elizabeth Mattijsen wrote: > At 22:30 -0600 12/21/03, Dave Rolsky wrote: > >On Sun, 21 Dec 2003, Ken Williams wrote: > > > I'd like to eventually move Module::Build development to perforce. I > > > can import the CVS history from the sourceforge project. I've set up a > > > server in my house on my DSL line. Not real heavy-duty, but it should > > > suffice. > > > Any objections? > >I for one prefer to use free software when possible. What's so great > >about Perforce that we shouldn't use it instead of Arch, Subversion, or > >one of a bazillion other free alternatives? > > I know that Subversion has been tried for the Ponie project. I think > I can still hear Arthur scream whenever Subversion gets mentioned. > It was particularly difficult to get any performance out of it with a > relatively large number of branches. My understanding is that the performance issues have been attacked with considerable vigour since then, and it's now quite a lot faster. I've found no problems with using it (as a client) on other projects. However, it's still moving, and they quite openly don't yet guarantee much backwards (binary) compatibility between minor versions. What no-one's yet mentioned is that perforce require you to renew the licence annually. I'm aware of 2 perl projects using perforce who were caught out by their licence running out, at which point they are locked out of their entire repository. Perforce seemed quite speedy in renewing the licence (considerably faster than the times officially promised) but this understandable desire of perforce to verify that they are not being conned results in frustrating beaurocracy. Nicholas Clark |
|
From: Ken W. <ke...@ma...> - 2003-12-22 19:47:12
|
On Sunday, December 21, 2003, at 10:30 PM, Dave Rolsky wrote: > > I for one prefer to use free software when possible. Me too, definitely. However, I also have a goal of supporting commercial companies that support open source work. I appreciate perforce's move to making their product free for open source work, and I think that if it's a better product the community can benefit from using it. And I tend to believe (I think) that open-source tools can achieve better "market penetration" if the companies that assist the movement can actually find ways to make The Big Bucks in doing so. Note that there are a lot of tools (API perl modules, conversion scripts, editor support, web repository browsers, bugzilla cooperation, etc.) that they release open source, and the only software that's actually for-pay is the server binary (I think). > What's so great > about Perforce that we shouldn't use it instead of Arch, Subversion, or > one of a bazillion other free alternatives? The two main things are that they have atomic commits of multiple files, and it's stable enough that they can get people to pay for it. They also integrate a job management (i.e. bug tracking) system in with the software, which I'd like to use, or at least try using. But another thing is that everyone I talk to who's used it seems to like it, which is probably worth a lot. -Ken |
|
From: Jim C. <jc...@di...> - 2003-12-22 16:25:09
|
MB already has these: requires recommends test_requires test_recommends seems a natural for things like Test::Warn, Test::Benchmark, etc.. I imagine there are CPAN, CPANPLUS, issues, and maybe indexing ones too. any thoughts ? |
|
From: Dave R. <au...@ur...> - 2003-12-22 16:18:51
|
On Mon, 22 Dec 2003, William McKee wrote: > On Mon, Dec 22, 2003 at 08:34:58AM -0600, James.FitzGibbon wrote: > > The likely culprit is that P::V is a requirement while the other two are > > only recommendations: > > Ahh, yes, I see. So why would a module author have tests that fail due > to modules that are only recommended. I guess this is less of a > Module::Build issue than a Thesaurus design issue. Sorry for the OT > traffic. Oops, that's just a test bug. Those tests should be skipped if you haven't installed the relevant modules. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Dave R. <au...@ur...> - 2003-12-22 16:16:40
|
On Mon, 22 Dec 2003, Elizabeth Mattijsen wrote: > At 22:30 -0600 12/21/03, Dave Rolsky wrote: > >On Sun, 21 Dec 2003, Ken Williams wrote: > > > I'd like to eventually move Module::Build development to perforce. I > > > can import the CVS history from the sourceforge project. I've set up a > > > server in my house on my DSL line. Not real heavy-duty, but it should > > > suffice. > > > Any objections? > >I for one prefer to use free software when possible. What's so great > >about Perforce that we shouldn't use it instead of Arch, Subversion, or > >one of a bazillion other free alternatives? > > I know that Subversion has been tried for the Ponie project. I think > I can still hear Arthur scream whenever Subversion gets mentioned. > It was particularly difficult to get any performance out of it with a > relatively large number of branches. I don't think it was the number of branches so much as the very large size of the repository (Perl + Parrot). But that won't be a problem here. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: William M. <wi...@kn...> - 2003-12-22 14:50:34
|
On Mon, Dec 22, 2003 at 08:34:58AM -0600, James.FitzGibbon wrote: > The likely culprit is that P::V is a requirement while the other two are > only recommendations: Ahh, yes, I see. So why would a module author have tests that fail due to modules that are only recommended. I guess this is less of a Module::Build issue than a Thesaurus design issue. Sorry for the OT traffic. William -- Knowmad Services Inc. http://www.knowmad.com |
|
From: James.FitzGibbon <Jam...@ta...> - 2003-12-22 14:35:11
|
The likely culprit is that P::V is a requirement while the other two are
only recommendations:
From Build.PL for the module:
requires =3D>
{ Params::Validate =3D> 0.24,
},
recommends =3D>
{ BerkeleyDB =3D> 0.19,
Text::CSV_XS =3D> 0,
},
If the module really can't be installed without those other two modules
then Dave should probably
promote them to requirements, but I'm sure he'll give a more coherent
explanation when he replies...
-----Original Message-----
From: mod...@li...
[mailto:mod...@li...] On Behalf Of
William McKee
Sent: Monday, December 22, 2003 8:05 AM
To: mod...@li...
Subject: [Module::Build] Bug Report - Thesaurus install feedback
Hi list,
I am in the process of learning to use Module::Build. While reading
Dave's article on Perl.com, I took his test of installing the Thesaurus
module via the CPAN shell to check how the make compatibility layer
would work.
It caught three missing modules. Unfortunately it only installed one, so
the install of Thesaurus failed. Manually installing the other two fixed
the problem. Why is Thesaurus not requiring these other two if it can't
be installed without them (other than by force)?
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D#
/usr/bin/perl Build.PL=20
Checking whether your kit is complete...
Looks good
ERROR: Params::Validate: Prerequisite Params::Validate isn't installed
WARNING: BerkeleyDB: Prerequisite BerkeleyDB isn't installed
WARNING: Text::CSV_XS: Prerequisite Text::CSV_XS isn't installed
ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the
versions of the modules indicated above before proceeding with this
installation.
Creating new 'Build' script for 'Thesaurus' version '0.21'
---- Unsatisfied dependencies detected during
[D/DR/DROLSKY/Thesaurus-0.21.tar.gz] -----
Params::Validate
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes]=20
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D#
Thanks,
William
--=20
Knowmad Services Inc.
http://www.knowmad.com
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's Free Linux Tutorials. Learn everything from the bash shell to sys
admin. Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Module-build-general mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: William M. <wi...@kn...> - 2003-12-22 14:05:08
|
Hi list, I am in the process of learning to use Module::Build. While reading Dave's article on Perl.com, I took his test of installing the Thesaurus module via the CPAN shell to check how the make compatibility layer would work. It caught three missing modules. Unfortunately it only installed one, so the install of Thesaurus failed. Manually installing the other two fixed the problem. Why is Thesaurus not requiring these other two if it can't be installed without them (other than by force)? #==============================================================# /usr/bin/perl Build.PL Checking whether your kit is complete... Looks good ERROR: Params::Validate: Prerequisite Params::Validate isn't installed WARNING: BerkeleyDB: Prerequisite BerkeleyDB isn't installed WARNING: Text::CSV_XS: Prerequisite Text::CSV_XS isn't installed ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation. Creating new 'Build' script for 'Thesaurus' version '0.21' ---- Unsatisfied dependencies detected during [D/DR/DROLSKY/Thesaurus-0.21.tar.gz] ----- Params::Validate Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] #==============================================================# Thanks, William -- Knowmad Services Inc. http://www.knowmad.com |
|
From: Autrijus T. <aut...@au...> - 2003-12-22 10:41:13
|
On Mon, Dec 22, 2003 at 09:29:18PM +1100, Iain Truskett wrote:
> * Elizabeth Mattijsen (li...@di...) [22 Dec 2003 20:23]:
> [...]
> > I know that Subversion has been tried for the Ponie
> > project. I think I can still hear Arthur scream whenever
> > Subversion gets mentioned. It was particularly difficult
> > to get any performance out of it with a relatively large
> > number of branches.
>
> Not that M::B will have quite so many branches as Perl.
Blatant plug: I've been using svk for a while to monitor
6 svn repositories (4 of which I also commit to), and in
addition to its bitkeeper-like offline working ability,
I also find svk to be much faster than svn's command line
client, approaching the speed of p4.
And since it's written in pure perl, it's also easily
hackable. :-)
http://svk.elixus.org/
Thanks,
/Autrijus/
|
|
From: Iain T. <tmd...@de...> - 2003-12-22 10:30:18
|
* Elizabeth Mattijsen (li...@di...) [22 Dec 2003 20:23]: [...] > I know that Subversion has been tried for the Ponie > project. I think I can still hear Arthur scream whenever > Subversion gets mentioned. It was particularly difficult > to get any performance out of it with a relatively large > number of branches. Not that M::B will have quite so many branches as Perl. cheers, -- Iain. |
|
From: Elizabeth M. <li...@di...> - 2003-12-22 09:23:30
|
At 22:30 -0600 12/21/03, Dave Rolsky wrote: >On Sun, 21 Dec 2003, Ken Williams wrote: > > I'd like to eventually move Module::Build development to perforce. I > > can import the CVS history from the sourceforge project. I've set up a > > server in my house on my DSL line. Not real heavy-duty, but it should > > suffice. > > Any objections? >I for one prefer to use free software when possible. What's so great >about Perforce that we shouldn't use it instead of Arch, Subversion, or >one of a bazillion other free alternatives? I know that Subversion has been tried for the Ponie project. I think I can still hear Arthur scream whenever Subversion gets mentioned. It was particularly difficult to get any performance out of it with a relatively large number of branches. I don't know about the bazillion other free alternatives. Liz |
|
From: Dave R. <au...@ur...> - 2003-12-22 04:30:59
|
On Sun, 21 Dec 2003, Ken Williams wrote: > I've secured a free 50-developer license to use Perforce for > open-source work (see > http://www.perforce.com/perforce/price.html#opensource ), and I think > it looks pretty good. For those who don't know, perl core development > has been using perforce for several years. It's *not* an open-source > product, but anyone can download client programs for free. > > I'd like to eventually move Module::Build development to perforce. I > can import the CVS history from the sourceforge project. I've set up a > server in my house on my DSL line. Not real heavy-duty, but it should > suffice. > > Any objections? I for one prefer to use free software when possible. What's so great about Perforce that we shouldn't use it instead of Arch, Subversion, or one of a bazillion other free alternatives? -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-12-22 03:40:23
|
Hi listies, I've secured a free 50-developer license to use Perforce for open-source work (see http://www.perforce.com/perforce/price.html#opensource ), and I think it looks pretty good. For those who don't know, perl core development has been using perforce for several years. It's *not* an open-source product, but anyone can download client programs for free. I'd like to eventually move Module::Build development to perforce. I can import the CVS history from the sourceforge project. I've set up a server in my house on my DSL line. Not real heavy-duty, but it should suffice. Any objections? -Ken |
|
From: Glenn L. <pe...@ne...> - 2003-12-22 01:46:02
|
On approximately 12/21/2003 5:31 PM, came the following characters from the keyboard of Glenn Linderman: > On approximately 12/21/2003 4:29 AM, came the following characters from > the keyboard of Jos I. Boumans: > >> >> On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: >> >>> At the cost of making the A::T code somewhat ugly, I think an imperfect >>> heuristic solution is possible, so that if all PATHs in the tarball were >>> less than 100 characters in length, A::T could write the whole path at >>> the front of the chunk and not use the 'prefix' field -- with a >>> different >>> code path, using the 'prefix' field, followed if any path in the tarball >>> exceeds 100 characters in length. >> >> >> i'm very much opposed to this solution, since this still doesn't actually >> /fix/ the problem; it's merely coding around a problem in /other/ tools, >> and it will introduce a very fun /new/ 'bug' that distributions that keep >> their longest path under 100 chars will do the right thing, and any >> distribution with a path > 100 chars will now break... id much rather >> document this shortcoming in other tools and add a dependency on a >> /proper/ tar extractor, that follows the specs for the tar format... >> A::T, >> gnu tar and quite a few others do... old bsd tars and some )"(#/"#) >> windows tools dont..... >> >> just my $0.02 >> >> -jos > > > Interesting point of view. That's sort of like outlawing all the old > cars that don't have some new safety feature, making it illegal to drive > them on the roads. > > Sure seems to me that a high percentage of the tarballs in the world > have mostly paths less than 100 characters. > > It is too bad that the old programs can look at the new tarball and see > a subset of the data, instead of reporting the real condition, at least > as a warning if not an error: "This tarball was produced using a version > of tar that implements a newer specification than this tar program. To > see the tarball in its full detail, you should use a tar program that > implements specification GHI. This tar program only implements > specification ABC." > > That would explain the situation to the user. > > On the other hand, for those tarballs that can be correctly created > according to the older specifications, without loss of functionality, > that is an extremely friendly feature even for a program that is capable > of creating tarballs using the new specifications, with new > functionality. This sort of thing is called "backward compatibility", > and it encourages people to use the new program, since it interoperates > with the old, instead of encouraging them to throw the new program away, > sticking with the old tried and true and interoperable programs. > > I have to admit that if I was under time pressure today to release my > new module (I still have a few weeks to go), that I would be extremely > tempted to discard both > > (1) Archive::Tar, > (2) Module::Build, > > because > > (A) the module that I built won't install properly using PPM (even > with A::T v1.07), > (B) I can't see the paths to the files using PowerArchiver 2001, > (C) I don't get warnings for each directory that is supposed to be in > the tarball, and (C) is supposed to read "I _do_ get warnings..." or maybe just "I get warnings..." > (D) I have other sample modules using MakeMaker and tar programs, > that do not suffer from (A), (B), and (C), so it is clearly a functional > path to take. > > Since I have some lead time, I'll wait and see how this plays out over > the next few weeks. People like backward compatibility, because it > makes things work. And when things don't work, because of incremental > versionitis, it is nice if there is a built in method for reporting that > that is why, instead of simply providing reduced functionality without > warning. Providing reduced functionality is OK, with the warning. So > if an old tar program can extract the data, but not put it in the right > place, that is OK, if it tells me that it the tarball is a newer version > that it might not be able to fully decode. > > The fact that there are bugs and deficiencies in old programs, however, > is no excuse for a new program not to be as backward compatible as it > can be. > > Personally, I'd rather see archives stored as .zip files, which at least > were designed to do both archiving and compression in one step, rather > than play the two-step jig of .tar.gz. But that's a whole 'nother > story, and an idea which probably won't get much momentum or attention, > because .tar.gz is there and works. Well, given my above woes, sort of. > -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |
|
From: Glenn L. <pe...@ne...> - 2003-12-22 01:31:11
|
On approximately 12/21/2003 4:29 AM, came the following characters from
the keyboard of Jos I. Boumans:
>
> On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote:
>
>>At the cost of making the A::T code somewhat ugly, I think an imperfect
>>heuristic solution is possible, so that if all PATHs in the tarball were
>>less than 100 characters in length, A::T could write the whole path at
>>the front of the chunk and not use the 'prefix' field -- with a different
>>code path, using the 'prefix' field, followed if any path in the tarball
>>exceeds 100 characters in length.
>
> i'm very much opposed to this solution, since this still doesn't actually
> /fix/ the problem; it's merely coding around a problem in /other/ tools,
> and it will introduce a very fun /new/ 'bug' that distributions that keep
> their longest path under 100 chars will do the right thing, and any
> distribution with a path > 100 chars will now break... id much rather
> document this shortcoming in other tools and add a dependency on a
> /proper/ tar extractor, that follows the specs for the tar format... A::T,
> gnu tar and quite a few others do... old bsd tars and some )"(#/"#)
> windows tools dont.....
>
> just my $0.02
>
> -jos
Interesting point of view. That's sort of like outlawing all the old
cars that don't have some new safety feature, making it illegal to drive
them on the roads.
Sure seems to me that a high percentage of the tarballs in the world
have mostly paths less than 100 characters.
It is too bad that the old programs can look at the new tarball and see
a subset of the data, instead of reporting the real condition, at least
as a warning if not an error: "This tarball was produced using a version
of tar that implements a newer specification than this tar program. To
see the tarball in its full detail, you should use a tar program that
implements specification GHI. This tar program only implements
specification ABC."
That would explain the situation to the user.
On the other hand, for those tarballs that can be correctly created
according to the older specifications, without loss of functionality,
that is an extremely friendly feature even for a program that is capable
of creating tarballs using the new specifications, with new
functionality. This sort of thing is called "backward compatibility",
and it encourages people to use the new program, since it interoperates
with the old, instead of encouraging them to throw the new program away,
sticking with the old tried and true and interoperable programs.
I have to admit that if I was under time pressure today to release my
new module (I still have a few weeks to go), that I would be extremely
tempted to discard both
(1) Archive::Tar,
(2) Module::Build,
because
(A) the module that I built won't install properly using PPM (even
with A::T v1.07),
(B) I can't see the paths to the files using PowerArchiver 2001,
(C) I don't get warnings for each directory that is supposed to be
in the tarball, and
(D) I have other sample modules using MakeMaker and tar programs,
that do not suffer from (A), (B), and (C), so it is clearly a functional
path to take.
Since I have some lead time, I'll wait and see how this plays out over
the next few weeks. People like backward compatibility, because it
makes things work. And when things don't work, because of incremental
versionitis, it is nice if there is a built in method for reporting that
that is why, instead of simply providing reduced functionality without
warning. Providing reduced functionality is OK, with the warning. So
if an old tar program can extract the data, but not put it in the right
place, that is OK, if it tells me that it the tarball is a newer version
that it might not be able to fully decode.
The fact that there are bugs and deficiencies in old programs, however,
is no excuse for a new program not to be as backward compatible as it
can be.
Personally, I'd rather see archives stored as .zip files, which at least
were designed to do both archiving and compression in one step, rather
than play the two-step jig of .tar.gz. But that's a whole 'nother
story, and an idea which probably won't get much momentum or attention,
because .tar.gz is there and works. Well, given my above woes, sort of.
--
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26
billion on revenue of $2.81 billion.
--from Reuters via
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
|
|
From: Glenn L. <pe...@ne...> - 2003-12-22 01:22:37
|
On approximately 12/21/2003 4:18 AM, came the following characters from the keyboard of Andrew Savige: > --- "Randy W. Sims" <Ra...@Th...> wrote: > >>On 12/20/2003 5:23 PM, Jos I. Boumans wrote: >> >>>On Sat, 20 Dec 2003, Ken Williams wrote: >>> >>> >>>>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >>>> >>>> >>>>>Well this atleast proves that the paths are there, thus it is not a >>>>>problem with M::B, but I think this is going to be a big issue for >>>>>Windows users. I think if it's possible for Archive::Tar to be better >>>>>compatible with other tools, it should. If I knew anything about the >>>>>tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>>>the maintainer. ;-) >>>> >>>>I have some kind of vague recollection that maybe this issue in >>>>Archive::Tar has been fixed privately by Kane and is just waiting for >>>>him to release it. >>>> >>>>Kane, can you put Glenn out of his misery? Or am I remembering wrong? >>> >>> >>>well, even though m::b may use A::T to build an archive, and ppm uses it >>>to extract, it may not be the same A::T -- AS perl ships with a very old >>>version of A::T which does not support the full tar standard (including >>>the prefix header). Several people have already advised AS to upgrade A::T >>>to a recent version, that works on win32 and actually supports most of the >>>spec... >>> >>>the easiest fix would be to require the client to have a::t > 1.00 to make >>>sure this doesn't happen, but i'm not sure how to enforce this... >> >>Hi Jos, >> >>Actually this problem is occuring in recent versions of Archive::Tar; In >>fact, it happens with a post 1.07 snapshot Andrew referred me to a while >>back when we were having other problems (warnings when directories are >>added to the tar). If Ken can confirm that he used 'perl Build dist' to >>create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that >>he used a recent version of Archive::Tar, I think that will narrow down >>the problem to something in the way tar files are created on Windows as >>opposed to other OSs. When I look at that dist in WinZip (one of the >>common programs on windows used to handle tar files), the directory >>structure is there. When I untar that dist and run 'perl Build dist' in >>it, the tar file created on Windows does not show the directory >>structure (although it is there as confirmed by some ported versions of >>gnu tar). So, the problem seems to be in the creation process on Windows... > > > Sorry, I've been too busy lately and haven't been following this thread > as closely as I should. One thing you should be aware of is trouble > ticket 4437 at: > http://rt.cpan.org/NoAuth/Bugs.html?Dist=Archive-Tar&ShowAll=1 > As discussed in detail in this thread, tarballs created by Archive::Tar > lose the directory information when unpacked/viewed with old versions of > tarball viewers/extractors that do not properly implement the latest tar > spec. IIRC, old versions of BSD tar and many versions of WinZip lose the > directory information. > > At the cost of making the A::T code somewhat ugly, I think an imperfect > heuristic solution is possible, so that if all PATHs in the tarball were > less than 100 characters in length, A::T could write the whole path at > the front of the chunk and not use the 'prefix' field -- with a different > code path, using the 'prefix' field, followed if any path in the tarball > exceeds 100 characters in length. AHA! This sounds like a comment from an expert in A::T! or at least in the changes to the tar spec over time! I appreciate the enlightenment it gives. So I can at least get a glimmering of understanding about the issue... I can infer from what was said that: * Old tar limited path names to 100 characters or less * New systems permit more than that (even old system permit more than that) * New tar implements new scheme for longer path names * Old tar programs don't understand the new scheme, and show file names only * For compatibility with the old programs and old specs, new programs could use the old scheme if the path names are less than 100 characters, which would work for many archives, actually. Sounds like a good idea to me. -- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates And here is why it is ridiculous: The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion. --from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment. |
|
From: Ken W. <ke...@ma...> - 2003-12-21 17:33:49
|
Hey list, van...@pa... tells me, via https://rt.cpan.org/Ticket/Display.html?id=4615 , that the pass-through Makefile is broken when using DMake (never heard of it) on Windows (never heard of it!). I've checked in the following change, anyone see a problem with it? -Ken =================================================================== diff -u -r1.34 -r1.35 --- lib/Module/Build/Compat.pm 20 Dec 2003 16:18:26 -0000 1.34 +++ lib/Module/Build/Compat.pm 21 Dec 2003 17:32:53 -0000 1.35 @@ -139,7 +139,7 @@ $perl -e unlink -e shift $makefile force_do_it : - + @ EOF # XXX - user might be using a different subclass =================================================================== |
|
From: Ken W. <ke...@ma...> - 2003-12-21 16:52:59
|
On Sunday, December 21, 2003, at 06:29 AM, Jos I. Boumans wrote: > > > On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: >> At the cost of making the A::T code somewhat ugly, I think an >> imperfect >> heuristic solution is possible, so that if all PATHs in the tarball >> were >> less than 100 characters in length, A::T could write the whole path at >> the front of the chunk and not use the 'prefix' field -- with a >> different >> code path, using the 'prefix' field, followed if any path in the >> tarball >> exceeds 100 characters in length. > i'm very much opposed to this solution, since this still doesn't > actually > /fix/ the problem; it's merely coding around a problem in /other/ > tools, Those other tools aren't broken, they're simply written to an older version of the TAR spec. And it seems really bad to produce tarballs that will silently fail with all such tools. You know, "backward compatibility" and all.... -Ken |
|
From: Ken W. <ke...@ma...> - 2003-12-21 16:33:02
|
On Sunday, December 21, 2003, at 02:39 AM, Randy W. Sims wrote: > If Ken can confirm that he used 'perl Build dist' to create the > 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that he used > a recent version of Archive::Tar, Well, I built it on OS X, and on Unixish platforms Module::Build will just use an external call to the 'tar' command. So Archive::Tar wasn't in the mix. -Ken |
|
From: Jim C. <jc...@di...> - 2003-12-21 15:18:41
|
I wanted to follow up on this problem, and restate for
clarity. (original at bottom).
Im using MB::Compat, ie: perl Makefile.PL ---> Makefile.
When 'perl5.6.2' is substituted for 'perl', things go wrong.
since 'perl5.6.2' is not an absolute path,
MB::find_perl_interpreter()s 1st attempt fails,
ie: 'File::Spec->file_name_is_absolute($perl = $^X) '
then '-f ($perl = $Config::Config{perlpath})',
succeeds, returning "/usr/local/bin/perl"
since my /usr/local/bin/perl is 5.8.2, not 5.6.2, all
manner of badness ensues. Makefile uses
/usr/local/bin/perl, but Build script contains
5.6.2 lib-paths etc, resulting in:
[jimc@harpo Data-Dumper-EasyOO-0.02-p1]$ make
/usr/local/bin/perl Build
Perl lib version (v5.6.2) doesn't match executable version
(v5.8.2) at
/usr/local/lib/perl5/5.6.2/i686-linux/Config.pm line 21.
This is due in part to value of $^X,
which is full path for 5.8.2, but not for others.
$> perl -e 'print "$^X\n"'
/usr/local/bin/perl5.8.2-threads
$> perl5.6.2 -e 'print "$^X\n"'
perl5.6.2
$> perl5.00503 -e 'print "$^X\n"'
perl5.00503
$> perl5.6.1 -e 'print "$^X\n"'
perl5.6.1
Its also clear that my %Config is wrong; due to a 5.6.2
-des build/install into /usr/local/bin/perl, and a 5.8.2
install on top. Since installs also appear to write
/usr/local/bin/perl$version, this could probably be fixed by
a CORE patch to make perlpath use the complete, versioned
name (ie /usr/local/bin/perl5.6.2 thats also? installed),
but there are a lot of perls already out there, and Im not
sure it wouldnt break other things.
So I see the following options:
1. use full path when 'making' for older perls
2. use my patch below (works for .21_01 too)
3. a more robust patch, something like
# make full pathname from filename
($perl) = grep { -x "$_/$^X "} File::Spec->path()
The attached patch takes this approach.
4. a warning in MB::Cookbook - I dont like this - the root
cause seems eminently fixable...
Jim Cromie wrote:
>
> when I use an older perl (ex: perl5.6.2) to build the Makefile,
> several things go wrong;
>
> 1. Makefile uses /usr/local/bin/perl, not /usr/local/bin/perl5.6.2
>
> all : force_do_it
> /usr/local/bin/perl Build
>
> This patch 'seems' to fix this prob (but does nothing for my separate
> hanging problem).
> I saw your Change notes about $^X unreliability, so this may not be
> the thing, but its a start..
>
> diff -ru Module-Build-0.21/lib/Module/Build/Base.pm
> Module-Build-0.21-mod/lib/Module/Build/Base.pm
> --- Module-Build-0.21/lib/Module/Build/Base.pm Wed Oct 15 19:25:18
> 2003
> +++ Module-Build-0.21-mod/lib/Module/Build/Base.pm Fri Nov 7
> 17:10:22 2003
> @@ -166,8 +166,8 @@
> sub find_perl_interpreter {
> my $perl;
> File::Spec->file_name_is_absolute($perl = $^X)
> - or -f ($perl = $Config::Config{perlpath})
> - or ($perl = $^X);
> + or ($perl = $^X)
> + or -f ($perl = $Config::Config{perlpath});
> return $perl;
> }
>
>
> 2. executable version mismatch.
>
>
> [root@harpo Module-Build-0.21]# perl5.6.2 Makefile.PL
> perl5.6.2 Build.PL
> Checking whether your kit is complete...
> Looks good
> WARNING: ExtUtils::ParseXS: Prerequisite ExtUtils::ParseXS isn't
> installed
> WARNING: YAML: Prerequisite YAML isn't installed
> ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the
> versions
> of the modules indicated above before proceeding with this installation.
>
> Deleting Build
> Removed previous script 'Build'
> Creating new 'Build' script for 'Module-Build' version '0.21'
> [root@harpo Module-Build-0.21]# make
> /usr/local/bin/perl Build
> Perl lib version (v5.6.2) doesn't match executable version (v5.8.2) at
> /usr/local/lib/perl5/5.6.2/i686-linux/Config.pm line 21.
>
>
> guidance appreciated,
> reqs for more info welcome,
>
> jimc
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>
> .
>
|
|
From: Randy W. S. <Ra...@Th...> - 2003-12-21 12:54:16
|
On 12/21/2003 7:29 AM, Jos I. Boumans wrote: > > On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: > >>At the cost of making the A::T code somewhat ugly, I think an imperfect >>heuristic solution is possible, so that if all PATHs in the tarball were >>less than 100 characters in length, A::T could write the whole path at >>the front of the chunk and not use the 'prefix' field -- with a different >>code path, using the 'prefix' field, followed if any path in the tarball >>exceeds 100 characters in length. > > i'm very much opposed to this solution, since this still doesn't actually > /fix/ the problem; it's merely coding around a problem in /other/ tools, > and it will introduce a very fun /new/ 'bug' that distributions that keep > their longest path under 100 chars will do the right thing, and any > distribution with a path > 100 chars will now break... id much rather > document this shortcoming in other tools and add a dependency on a > /proper/ tar extractor, that follows the specs for the tar format... A::T, > gnu tar and quite a few others do... old bsd tars and some )"(#/"#) > windows tools dont..... > > just my $0.02 > > -jos > I don't believe this is the same problem. This is a problem where a tar file created on non-windows works but a tar file created on windows does not. I uploaded two tar files to: <http://www.thepierianspring.org/Archive-Tar-1.07.tar> <http://www.thepierianspring.org/ptar.tar> Both where created with the old ptar script from ~ 0.23. The first is a tar of Archive::Tar 1.07 release from CPAN. A cat shows all the files stored as expected but without path info. The second is a copy of the ptar script renamed to ptar/ptar.pl. A cat shows the file name as '.pl' and no path info. 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: Jos I. B. <ka...@dw...> - 2003-12-21 12:29:28
|
On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote: > At the cost of making the A::T code somewhat ugly, I think an imperfect > heuristic solution is possible, so that if all PATHs in the tarball were > less than 100 characters in length, A::T could write the whole path at > the front of the chunk and not use the 'prefix' field -- with a different > code path, using the 'prefix' field, followed if any path in the tarball > exceeds 100 characters in length. i'm very much opposed to this solution, since this still doesn't actually /fix/ the problem; it's merely coding around a problem in /other/ tools, and it will introduce a very fun /new/ 'bug' that distributions that keep their longest path under 100 chars will do the right thing, and any distribution with a path > 100 chars will now break... id much rather document this shortcoming in other tools and add a dependency on a /proper/ tar extractor, that follows the specs for the tar format... A::T, gnu tar and quite a few others do... old bsd tars and some )"(#/"#) windows tools dont..... just my $0.02 -jos |
|
From: <ajs...@ya...> - 2003-12-21 12:18:26
|
--- "Randy W. Sims" <Ra...@Th...> wrote: > On 12/20/2003 5:23 PM, Jos I. Boumans wrote: > > > > On Sat, 20 Dec 2003, Ken Williams wrote: > > > >>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: > >> > >>>Well this atleast proves that the paths are there, thus it is not a > >>>problem with M::B, but I think this is going to be a big issue for > >>>Windows users. I think if it's possible for Archive::Tar to be better > >>>compatible with other tools, it should. If I knew anything about the > >>>tar format, I'd try to provide a patch. Since I don't, I'll just cc > >>>the maintainer. ;-) > >> > >>I have some kind of vague recollection that maybe this issue in > >>Archive::Tar has been fixed privately by Kane and is just waiting for > >>him to release it. > >> > >>Kane, can you put Glenn out of his misery? Or am I remembering wrong? > > > > > > well, even though m::b may use A::T to build an archive, and ppm uses it > > to extract, it may not be the same A::T -- AS perl ships with a very old > > version of A::T which does not support the full tar standard (including > > the prefix header). Several people have already advised AS to upgrade A::T > > to a recent version, that works on win32 and actually supports most of the > > spec... > > > > the easiest fix would be to require the client to have a::t > 1.00 to make > > sure this doesn't happen, but i'm not sure how to enforce this... > > Hi Jos, > > Actually this problem is occuring in recent versions of Archive::Tar; In > fact, it happens with a post 1.07 snapshot Andrew referred me to a while > back when we were having other problems (warnings when directories are > added to the tar). If Ken can confirm that he used 'perl Build dist' to > create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that > he used a recent version of Archive::Tar, I think that will narrow down > the problem to something in the way tar files are created on Windows as > opposed to other OSs. When I look at that dist in WinZip (one of the > common programs on windows used to handle tar files), the directory > structure is there. When I untar that dist and run 'perl Build dist' in > it, the tar file created on Windows does not show the directory > structure (although it is there as confirmed by some ported versions of > gnu tar). So, the problem seems to be in the creation process on Windows... Sorry, I've been too busy lately and haven't been following this thread as closely as I should. One thing you should be aware of is trouble ticket 4437 at: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Archive-Tar&ShowAll=1 As discussed in detail in this thread, tarballs created by Archive::Tar lose the directory information when unpacked/viewed with old versions of tarball viewers/extractors that do not properly implement the latest tar spec. IIRC, old versions of BSD tar and many versions of WinZip lose the directory information. At the cost of making the A::T code somewhat ugly, I think an imperfect heuristic solution is possible, so that if all PATHs in the tarball were less than 100 characters in length, A::T could write the whole path at the front of the chunk and not use the 'prefix' field -- with a different code path, using the 'prefix' field, followed if any path in the tarball exceeds 100 characters in length. /-\ http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. |
7 messages has been excluded from this view by a project administrator.
