Thread: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: demerphq <dem...@gm...> - 2006-04-09 21:16:50
|
Hi All,
I am now one of the co-maintainers of ExtUtils-Install, and i have
released the first standalone of the distro as ExtUtils-Install-1.38
Testing and etc on non-win32 platforms would be really appreciated.
Notable changes are better Win32 support for in-use files, and support
for an INSTALL.SKIP file to prevent stuff being installed that
shouldnt be. This should be particularly useful for folks that use SVN
and would like to be able to do an install directly from their working
directory without install svn directories into their perl module tree.
If no bugs are reported in the next few weeks ill put together a patch
to synch blead.
Cheers,
Yves
---------- Forwarded message ----------
From: PAUSE <up...@pa...>
Date: Apr 9, 2006 11:09 PM
Subject: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz
To: Yves <dem...@gm...>
The uploaded file
ExtUtils-Install-1.38.tar.gz
has entered CPAN as
file: $CPAN/authors/id/Y/YV/YVES/ExtUtils-Install-1.38.tar.gz
size: 54015 bytes
md5: 15219e1cc3b7a33a1aa2f4e24559ad56
No action is required on your part
Request entered by: YVES (Yves)
Request entered on: Sun, 09 Apr 2006 21:08:43 GMT
Request completed: Sun, 09 Apr 2006 21:09:07 GMT
Thanks,
--
paused, v460
--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
|
|
From: Randy W. S. <ml...@th...> - 2006-04-10 08:11:36
|
demerphq wrote: > On 4/10/06, Randy W. Sims <ml...@th...> wrote: >>It's a bug in Archive::Tar that we were not able to resolve with the >>maintainer. The directories are there, but some Windows programs can't >>see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and >>Cygwin can read them. The newest WinRAR can. Maybe 7-zip? > > > Ok it didnt occur to me it might be a problem with winzip, so ill > investigate using other tools. I also noticed that the tar/gzip > produced by EUMM was about 5-10k smaller. But IMO having a problem > with Winzip is a pretty big problem. :-) Yup. > And to be honest im not so sure about using Archive::Tar as a first > option. I recall from previous times looking at it that its horribly > inefficient when dealing with larger file sizes (possibly this has > been resolved). IMO it would probably be preferable to let tar do the > work if its available. Is there some way I can tell MB that i would > prefer that it use a shell tool instead of pure perl stuff? (Im > cheating here, as i havent looked at the docs of MB to see if an > answer is there :-) Is there a tar program that works on Windows? I've tried quite a few but could find any that could /create/ an archive on Windows, other than with Cygwin. perl Build dist --tar C:\bin\tar.exe --gzip C:\bin\gzip.exe >>I don't know how to resolve this issue. Since Archive::Tar is now in >>perl core, it may be worth bringing up there? Other tar programs, like >>GNU tar, create archives that work correctly in any archive tool. > > > Once i understand the problem I definately will bring it up with the > maintainers. Im pretty sure this wasnt a problem in older versions. <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/> >>>So all I did was a >>> >>> nmake dist >>> >>>So regarding the executable bits being set, my assumption is that >>>tar/gzip when run from the cmd.exe shell gets permissions wrong? >> >>I never really noticed this before. Will have to check into it. Windows >>doesn't have equivelant file modes, but I would expect it to err on the >>side of leaving the executable bit unset... > > > Ive not noticed it specifically either, but that doesnt mean anything. > I have experienced _general_ odd problems with unpacking files > sometimes. Some compression tools manage to pack the files so when i > unpack them they have Win32 ownership rights for people who arent > registered on my machine, meaning i have to retake ownership of them > before I can use them, ive also seen odd attributes being applied for > no apparent reason. Ive never bothered to look into it deeper than how > to override the problem tho. I'll need to investigate this at some point for Module::Build. See what happens when dist is run on Windows... Randy. |
|
From: demerphq <dem...@gm...> - 2006-04-10 08:33:28
|
On 4/10/06, Randy W. Sims <ml...@th...> wrote: > demerphq wrote: > > On 4/10/06, Randy W. Sims <ml...@th...> wrote: > >>It's a bug in Archive::Tar that we were not able to resolve with the > >>maintainer. The directories are there, but some Windows programs can't > >>see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and > >>Cygwin can read them. The newest WinRAR can. Maybe 7-zip? > > > > > > Ok it didnt occur to me it might be a problem with winzip, so ill > > investigate using other tools. I also noticed that the tar/gzip > > produced by EUMM was about 5-10k smaller. But IMO having a problem > > with Winzip is a pretty big problem. :-) > > Yup. Maybet MB should probe for tar and if its found use it on win32 as a preference? Most people doing module release on Win32 will have tar installed IMO, one way or another. > Is there a tar program that works on Windows? I've tried quite a few but > could find any that could /create/ an archive on Windows, other than > with Cygwin. > > perl Build dist --tar C:\bin\tar.exe --gzip C:\bin\gzip.exe Ok. Well thats simple. Ill play around with it and see whats up. And regarding tar/gzip i use the cygwin ones. They work fine from cmd.exe. Ive also used other ports and they worked ok too. But I tend to stick to cygwin ones. Although i do recall that one trick with using them from cmd.exe is to use relative paths only, ie cd into a directory such that you can do a relative path. > >>I don't know how to resolve this issue. Since Archive::Tar is now in > >>perl core, it may be worth bringing up there? Other tar programs, like > >>GNU tar, create archives that work correctly in any archive tool. > > > > > > Once i understand the problem I definately will bring it up with the > > maintainers. Im pretty sure this wasnt a problem in older versions. > > <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/> > <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/> Oooh. Big threads. :-) Ill have to review them. > >>>So all I did was a > >>> > >>> nmake dist > >>> > >>>So regarding the executable bits being set, my assumption is that > >>>tar/gzip when run from the cmd.exe shell gets permissions wrong? > >> > >>I never really noticed this before. Will have to check into it. Windows > >>doesn't have equivelant file modes, but I would expect it to err on the > >>side of leaving the executable bit unset... > > > > > > Ive not noticed it specifically either, but that doesnt mean anything. > > I have experienced _general_ odd problems with unpacking files > > sometimes. Some compression tools manage to pack the files so when i > > unpack them they have Win32 ownership rights for people who arent > > registered on my machine, meaning i have to retake ownership of them > > before I can use them, ive also seen odd attributes being applied for > > no apparent reason. Ive never bothered to look into it deeper than how > > to override the problem tho. > > I'll need to investigate this at some point for Module::Build. See what > happens when dist is run on Windows... Well, I checked my Archive::Tar version and apparently its up to date. So at this point on my .27 patched I have a problem with the dist creation. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: demerphq <dem...@gm...> - 2006-04-14 16:37:22
|
On 4/10/06, Randy W. Sims <ml...@th...> wrote: > demerphq wrote: > > On 4/10/06, Randy W. Sims <ml...@th...> wrote: > >>I don't know how to resolve this issue. Since Archive::Tar is now in > >>perl core, it may be worth bringing up there? Other tar programs, like > >>GNU tar, create archives that work correctly in any archive tool. > > > > > > Once i understand the problem I definately will bring it up with the > > maintainers. Im pretty sure this wasnt a problem in older versions. > > <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/> > <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/> Ok, ive created a new bug report and patches to fix this. You can see them = at: http://rt.cpan.org//Ticket/Display.html?id=3D18720 I actually asked RT to cc the list, but as I didnt see anything come through I figured Id send out a heads up. Cheers, Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Ken W. <ke...@ma...> - 2006-04-10 00:57:36
|
On Apr 9, 2006, at 4:16 PM, demerphq wrote: > Notable changes are better Win32 support for in-use files Awesome, glad to hear this is released now. -Ken |
|
From: Rafael Garcia-S. <rga...@gm...> - 2006-04-09 21:20:59
|
On 09/04/06, demerphq <dem...@gm...> wrote: > Notable changes are better Win32 support for in-use files, and support > for an INSTALL.SKIP file to prevent stuff being installed that > shouldnt be. This should be particularly useful for folks that use SVN > and would like to be able to do an install directly from their working > directory without install svn directories into their perl module tree. How does the purpose of this file differ from the one of MANIFEST.SKIP ? |
|
From: demerphq <dem...@gm...> - 2006-04-09 21:36:21
|
On 4/9/06, Rafael Garcia-Suarez <rga...@gm...> wrote: > On 09/04/06, demerphq <dem...@gm...> wrote: > > Notable changes are better Win32 support for in-use files, and support > > for an INSTALL.SKIP file to prevent stuff being installed that > > shouldnt be. This should be particularly useful for folks that use SVN > > and would like to be able to do an install directly from their working > > directory without install svn directories into their perl module tree. > > How does the purpose of this file differ from the one of MANIFEST.SKIP ? ExtUtils::Install::install() pays no attention to MANIFEST.SKIP and never h= as. MANIFEST.SKIP is to prevent stuff from getting added to MANIFEST when you do something like make manifest which is a distinct process from installation.Installation is performed by doing stuff like moving all files under one path to another path, INSTALL.SKIP allows you to prevent specific filetypes or files from being included in such a process. Examples uses for this could be on Win32 to filter out the installation of XS/C compilation byproduct like *.pdb. I personally use it for stuff like preventing .bak from getting installed and for keeping .svn out of my site/lib tree. In ex-ExtUtils-Install-1.3702 I made the mistake of letting MANIFEST.SKIP be used when no INSTALL.SKIP was present but this prevented some packages from installing as their MANIFEST.SKIP contained the patter /blib/ which as it is in most install source paths meant that nothing would get installed at all. 1.38 fixes this problem by using INSTALL.SKIP only, but allows EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic use. Cheers, Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Rafael Garcia-S. <rga...@gm...> - 2006-04-09 23:05:56
|
On 09/04/06, demerphq <dem...@gm...> wrote: > In ex-ExtUtils-Install-1.3702 I made the mistake of letting > MANIFEST.SKIP be used when no INSTALL.SKIP was present but this > prevented some packages from installing as their MANIFEST.SKIP > contained the patter /blib/ which as it is in most install source > paths meant that nothing would get installed at all. 1.38 fixes this > problem by using INSTALL.SKIP only, but allows > EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic > use. OK, that was the explanation I was looking for :) Thanks. |
|
From: Nick Ing-S. <ni...@in...> - 2006-04-11 19:26:44
|
Demerphq <dem...@gm...> writes: >On 4/9/06, Rafael Garcia-Suarez <rga...@gm...> wrote: >> On 09/04/06, demerphq <dem...@gm...> wrote: >> > Notable changes are better Win32 support for in-use files, and support >> > for an INSTALL.SKIP file to prevent stuff being installed that >> > shouldnt be. This should be particularly useful for folks that use SVN >> > and would like to be able to do an install directly from their working >> > directory without install svn directories into their perl module tree. >> >> How does the purpose of this file differ from the one of MANIFEST.SKIP ? > >ExtUtils::Install::install() pays no attention to MANIFEST.SKIP and never = has. And shouldn't. In many cases they are inverses! It is quite reasonable to have something in MANIFEST.SKIP because the=20 build process generates it e.g. exclude Foo when there is a Foo.PL that bui= lds it. When you install though you may want to install generated Foo but NOT= =20 Foo.PL (and later can look like something to install Foo.pl on case ignorin= g=20 systems.) > >MANIFEST.SKIP is to prevent stuff from getting added to MANIFEST when >you do something like > > make manifest > >which is a distinct process from installation.Installation is >performed by doing stuff like moving all files under one path to >another path, INSTALL.SKIP allows you to prevent specific filetypes or >files from being included in such a process. > >Examples uses for this could be on Win32 to filter out the >installation of XS/C compilation byproduct like *.pdb. I personally >use it for stuff like preventing .bak from getting installed and for >keeping .svn out of my site/lib tree. > >In ex-ExtUtils-Install-1.3702 I made the mistake of letting >MANIFEST.SKIP be used when no INSTALL.SKIP was present but this >prevented some packages from installing as their MANIFEST.SKIP >contained the patter /blib/ which as it is in most install source >paths meant that nothing would get installed at all. 1.38 fixes this >problem by using INSTALL.SKIP only, but allows >EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic >use. > >Cheers, >Yves |
|
From: Randy W. S. <ml...@th...> - 2006-04-10 06:30:27
Attachments:
nonono.diff
|
demerphq wrote: > Hi All, > > I am now one of the co-maintainers of ExtUtils-Install, and i have > released the first standalone of the distro as ExtUtils-Install-1.38 Excellent. Great work on this. May I belatedly point out another quick patchlet? I've been looking at the Module::Build RT queue and found ticket #16188[1] which also exists in the MakeMaker queue as ticket #16225[2]. Scwhern's suversion repository is down so I can't investigate what led to the current code; it looks like a straightfoward fix though... Thanks, Randy. 1. <http://rt.cpan.org/Public/Bug/Display.html?id=16188> 2. <http://rt.cpan.org/Public/Bug/Display.html?id=16225> |
|
From: Randy W. S. <ml...@th...> - 2006-04-10 06:50:48
|
Randy W. Sims wrote: > demerphq wrote: > >> Hi All, >> >> I am now one of the co-maintainers of ExtUtils-Install, and i have >> released the first standalone of the distro as ExtUtils-Install-1.38 > > > Excellent. Great work on this. > BTW, How did you create the distribution? I notice that every file in the distribution is set to file mode 0755 on *nix, which is to say that all the files have the executable bit set. Weird. Randy. |
|
From: demerphq <dem...@gm...> - 2006-04-10 07:09:32
|
On 4/10/06, Randy W. Sims <ml...@th...> wrote: > Randy W. Sims wrote: > > demerphq wrote: > > > >> Hi All, > >> > >> I am now one of the co-maintainers of ExtUtils-Install, and i have > >> released the first standalone of the distro as ExtUtils-Install-1.38 > > > > > > Excellent. Great work on this. > > > > BTW, How did you create the distribution? I notice that every file in > the distribution is set to file mode 0755 on *nix, which is to say that > all the files have the executable bit set. Weird. Actually I wanted to bring a couple of things up with you guys but havent gotten around to it yet. When i tried build dist the resulting tar.gz contained no paths, all files were in a single flat directory. When i did it with EU::MM the proper tree was created. But im currently using an older beta release of MB so its quite possible this is a bug that has been fixed. So all I did was a nmake dist So regarding the executable bits being set, my assumption is that tar/gzip when run from the cmd.exe shell gets permissions wrong? Cheers, Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: Randy W. S. <ml...@th...> - 2006-04-10 07:34:38
|
demerphq wrote: > On 4/10/06, Randy W. Sims <ml...@th...> wrote: > >>Randy W. Sims wrote: >> >>>demerphq wrote: >>> >>> >>>>Hi All, >>>> >>>>I am now one of the co-maintainers of ExtUtils-Install, and i have >>>>released the first standalone of the distro as ExtUtils-Install-1.38 >>> >>> >>>Excellent. Great work on this. >>> >> >>BTW, How did you create the distribution? I notice that every file in >>the distribution is set to file mode 0755 on *nix, which is to say that >>all the files have the executable bit set. Weird. > > > Actually I wanted to bring a couple of things up with you guys but > havent gotten around to it yet. > > When i tried > > build dist > > the resulting tar.gz contained no paths, all files were in a single > flat directory. When i did it with EU::MM the proper tree was created. > But im currently using an older beta release of MB so its quite > possible this is a bug that has been fixed. It's a bug in Archive::Tar that we were not able to resolve with the maintainer. The directories are there, but some Windows programs can't see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and Cygwin can read them. The newest WinRAR can. Maybe 7-zip? I don't know how to resolve this issue. Since Archive::Tar is now in perl core, it may be worth bringing up there? Other tar programs, like GNU tar, create archives that work correctly in any archive tool. > So all I did was a > > nmake dist > > So regarding the executable bits being set, my assumption is that > tar/gzip when run from the cmd.exe shell gets permissions wrong? I never really noticed this before. Will have to check into it. Windows doesn't have equivelant file modes, but I would expect it to err on the side of leaving the executable bit unset... Randy. |
|
From: demerphq <dem...@gm...> - 2006-04-10 07:54:23
|
On 4/10/06, Randy W. Sims <ml...@th...> wrote: > demerphq wrote: > > On 4/10/06, Randy W. Sims <ml...@th...> wrote: > > > >>Randy W. Sims wrote: > >> > >>>demerphq wrote: > >>> > >>> > >>>>Hi All, > >>>> > >>>>I am now one of the co-maintainers of ExtUtils-Install, and i have > >>>>released the first standalone of the distro as ExtUtils-Install-1.38 > >>> > >>> > >>>Excellent. Great work on this. > >>> > >> > >>BTW, How did you create the distribution? I notice that every file in > >>the distribution is set to file mode 0755 on *nix, which is to say that > >>all the files have the executable bit set. Weird. > > > > > > Actually I wanted to bring a couple of things up with you guys but > > havent gotten around to it yet. > > > > When i tried > > > > build dist > > > > the resulting tar.gz contained no paths, all files were in a single > > flat directory. When i did it with EU::MM the proper tree was created. > > But im currently using an older beta release of MB so its quite > > possible this is a bug that has been fixed. > > It's a bug in Archive::Tar that we were not able to resolve with the > maintainer. The directories are there, but some Windows programs can't > see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and > Cygwin can read them. The newest WinRAR can. Maybe 7-zip? Ok it didnt occur to me it might be a problem with winzip, so ill investigate using other tools. I also noticed that the tar/gzip produced by EUMM was about 5-10k smaller. But IMO having a problem with Winzip is a pretty big problem. :-) And to be honest im not so sure about using Archive::Tar as a first option. I recall from previous times looking at it that its horribly inefficient when dealing with larger file sizes (possibly this has been resolved). IMO it would probably be preferable to let tar do the work if its available. Is there some way I can tell MB that i would prefer that it use a shell tool instead of pure perl stuff? (Im cheating here, as i havent looked at the docs of MB to see if an answer is there :-) > I don't know how to resolve this issue. Since Archive::Tar is now in > perl core, it may be worth bringing up there? Other tar programs, like > GNU tar, create archives that work correctly in any archive tool. Once i understand the problem I definately will bring it up with the maintainers. Im pretty sure this wasnt a problem in older versions. > > So all I did was a > > > > nmake dist > > > > So regarding the executable bits being set, my assumption is that > > tar/gzip when run from the cmd.exe shell gets permissions wrong? > > I never really noticed this before. Will have to check into it. Windows > doesn't have equivelant file modes, but I would expect it to err on the > side of leaving the executable bit unset... Ive not noticed it specifically either, but that doesnt mean anything. I have experienced _general_ odd problems with unpacking files sometimes. Some compression tools manage to pack the files so when i unpack them they have Win32 ownership rights for people who arent registered on my machine, meaning i have to retake ownership of them before I can use them, ive also seen odd attributes being applied for no apparent reason. Ive never bothered to look into it deeper than how to override the problem tho. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
|
From: demerphq <dem...@gm...> - 2006-04-10 07:04:07
|
On 4/10/06, Randy W. Sims <ml...@th...> wrote: > demerphq wrote: > > Hi All, > > > > I am now one of the co-maintainers of ExtUtils-Install, and i have > > released the first standalone of the distro as ExtUtils-Install-1.38 > > Excellent. Great work on this. > > May I belatedly point out another quick patchlet? I've been looking at > the Module::Build RT queue and found ticket #16188[1] which also exists > in the MakeMaker queue as ticket #16225[2]. Scwhern's suversion > repository is down so I can't investigate what led to the current code; > it looks like a straightfoward fix though... > > Thanks, > Randy. > > 1. <http://rt.cpan.org/Public/Bug/Display.html?id=3D16188> > 2. <http://rt.cpan.org/Public/Bug/Display.html?id=3D16225> Sure no problem, Ill follow up on this as soon as I can. Thanks for bringing it to my attention. cheers, Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X