The scala tarball doesn't extract into a new subdirectory and instead just extracts into the directory where you run tar, i.e. a tarbomb. So in work/, you see a bin/ and a share/ directory. Is there an easy, clean way to deal with this in MacPorts? I looked at specifying some extract options, but I didn't see anything. I tried passing the ${distname} to tar -C's option to create the subdirectory, but this doesn't work, since the directory to put it in doesn't exist yet. It looks like another way is to hack it into configure to move the directories down a level, but this doesn't seem clean. Any ideas? Regards, Blair
On Apr 5, 2007, at 3:54 PM, Blair Zajac wrote:
The scala tarball doesn't extract into a new subdirectory and instead just extracts into the directory where you run tar, i.e. a tarbomb. So in work/, you see a bin/ and a share/ directory.
Is there an easy, clean way to deal with this in MacPorts? I looked at specifying some extract options, but I didn't see anything. I tried passing the ${distname} to tar -C's option to create the subdirectory, but this doesn't work, since the directory to put it in doesn't exist yet.
You could create the subdirectory in pre-extract and then do the above. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Thu, Apr 05, 2007 at 12:54:33PM -0700, Blair Zajac wrote:
The scala tarball doesn't extract into a new subdirectory and instead just extracts into the directory where you run tar, i.e. a tarbomb. So in work/, you see a bin/ and a share/ directory.
Is there an easy, clean way to deal with this in MacPorts? I looked at specifying some extract options, but I didn't see anything. I tried passing the ${distname} to tar -C's option to create the subdirectory, but this doesn't work, since the directory to put it in doesn't exist yet.
It looks like another way is to hack it into configure to move the directories down a level, but this doesn't seem clean.
The netcat port handles this problem with: pre-extract { system "mkdir -p ${worksrcpath}" } extract.dir ${worksrcpath} -eric
Daniel J. Luke wrote:
On Apr 5, 2007, at 3:54 PM, Blair Zajac wrote:
The scala tarball doesn't extract into a new subdirectory and instead just extracts into the directory where you run tar, i.e. a tarbomb. So in work/, you see a bin/ and a share/ directory.
Is there an easy, clean way to deal with this in MacPorts? I looked at specifying some extract options, but I didn't see anything. I tried passing the ${distname} to tar -C's option to create the subdirectory, but this doesn't work, since the directory to put it in doesn't exist yet.
You could create the subdirectory in pre-extract and then do the above.
Thanks, that did the trick. Reading portfile and looking through the source, I didn't see that option. Regards, Blair
Eric Hall wrote:
On Thu, Apr 05, 2007 at 12:54:33PM -0700, Blair Zajac wrote:
The scala tarball doesn't extract into a new subdirectory and instead just extracts into the directory where you run tar, i.e. a tarbomb. So in work/, you see a bin/ and a share/ directory.
Is there an easy, clean way to deal with this in MacPorts? I looked at specifying some extract options, but I didn't see anything. I tried passing the ${distname} to tar -C's option to create the subdirectory, but this doesn't work, since the directory to put it in doesn't exist yet.
It looks like another way is to hack it into configure to move the directories down a level, but this doesn't seem clean.
The netcat port handles this problem with:
pre-extract { system "mkdir -p ${worksrcpath}" } extract.dir ${worksrcpath}
Thanks, that's what I ended up going with, however, using file mkdir ${worksrcpath} instead of the system. Regards, Blair
Elias Pipping wrote:
On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
Thanks, that's what I ended up going with, however, using file mkdir ${worksrcpath} instead of the system.
how about 'xinstall -d'?
Don't the 'file subcommands' commands not shell out? Which is a good thing to practice. Regards, Blair
On Apr 5, 2007, at 7:05 PM, Blair Zajac wrote:
Elias Pipping wrote:
On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
Thanks, that's what I ended up going with, however, using file mkdir ${worksrcpath} instead of the system.
how about 'xinstall -d'?
Don't the 'file subcommands' commands not shell out? Which is a good thing to practice.
Regards, Blair
Shelling out is indeed something to avoid, which is why xinstall is also a good choice as it doesn't shell out either. xinstall is a MacPorts built-in command written in C and defined in svn base/src/pextlib1.0/xinstall.{c,h}. File commands and xinstall flags differ in their handling of extended attributes as documented in portfile(7), but in the case of creating directories I'd think they're completely equivalent. HTH! -jmpp
On Apr 5, 2007, at 8:20 PM, Juan Manuel Palacios wrote:
On Apr 5, 2007, at 7:05 PM, Blair Zajac wrote:
Elias Pipping wrote:
On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
Thanks, that's what I ended up going with, however, using file mkdir ${worksrcpath} instead of the system.
how about 'xinstall -d'?
Don't the 'file subcommands' commands not shell out? Which is a good thing to practice.
Regards, Blair
Shelling out is indeed something to avoid, which is why xinstall is also a good choice as it doesn't shell out either. xinstall is a MacPorts built-in command written in C and defined in svn base/src/ pextlib1.0/xinstall.{c,h}. File commands and xinstall flags differ in their handling of extended attributes as documented in portfile (7), but in the case of creating directories I'd think they're completely equivalent.
HTH!
Thanks Jaun, That's good information to know. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
participants (5)
-
Blair Zajac
-
Daniel J. Luke
-
Elias Pipping
-
Eric Hall
-
Juan Manuel Palacios