[gobolinux-devel] Compile dir detection
I am not sure about the necessity for the 'dir' argument in Recipes.
Right now, I am trying to update the Foomatic recipe for 4.0, and it
has a mess in it about figuring out what the $dir should be.
It would seem reasonable to examine the archive file to find out where
the files will be unpacked, and just set $dir to that; and if there's
more than one top-level name, create a dir and unpack inside it. Are
there any problems with this approach?
Here is some bash code which works just fine for me. It can be
considered pseudo-code, though, since I don't know the proper names
for "$archiveDir", "$ProgramName", or so forth (but I trust their
meaning is self-evident.) Also, I assume there's some methodology in
place for dealing with different types of archives, and you'd want to
plug into that instead of using this case statement.
function ziplist() {
unzip -l $1 | sed -re '0,/( +-+){4}/d; /( +-+){2}/,$d; s/ *[0-9]*
*[0-9-]* *[0-9:]* *//'
}
unset multifile ddd dir list_cmd extract_cmd
case $archive_file in
*.tar|*.tar.*|*.t[gbxl7]z|*.tbz2)
list_cmd="tar tf"# Did you realize this just works for
gzipped, bzipped, xzipped, lzopped, etc files?
extract_cmd="tar xf" ;; # I didn't! But it does!
*.zip)
list_cmd=ziplist
extract_cmd=unzip ;;
*)
if which atool > /dev/null
then list_cmd="atool -l"
extract_cmd="atool -x"
else echo "Agh"
fi ;;
esac #is ridiculous
for ddd in `$list_cmd $archiveDir/$archive_file`
do ddd="${ddd#./}"
ddd="${ddd%%/*}"
if [[ -n "$dir" && "$ddd" != "$dir" ]]
then multifile=1
elif [[ -z "$dir" ]]
then dir="$ddd"
fi
done
if [[ "$multifile" == 1 ]]
then dir="$ProgramName-$ProgramVersion"
mkdir $dir
cd $dir
$extract_cmd $archiveDir/$archive_file
else
$extract_cmd $archiveDir/$archive_file
cd $dir
fi
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Compile dir detection
On Friday 20 March 2009 16:23:46 Nick Matteo wrote: > I am not sure about the necessity for the 'dir' argument in Recipes. > Right now, I am trying to update the Foomatic recipe for 4.0, and it > has a mess in it about figuring out what the $dir should be. > > It would seem reasonable to examine the archive file to find out where > the files will be unpacked, and just set $dir to that; and if there's > more than one top-level name, create a dir and unpack inside it. Are > there any problems with this approach? That you have to decompress a potentially large file twice for no reason. Foomatic-DB seems to be a pathological case where the dirname changes for the same URL, where that name detection could be useful; if there are others like that it could be a reasonable mode to have. The rest of the time, the default usually works, dir almost always works, and files_in_root covers the other occasional case. None of those benefit from the extra decompression, so they shouldn't have to pay that cost (which will be big for, say, Linux). If Foomatic-DB is the only one that needs it, it should just be special-cased into the recipe like it is now (maintenance is where it belongs then, rather than elsewhere that it will bit-rot). Otherwise adding an uncompress=detect_destination would be fine. Your code looks like a decent draft implementation of that. -Michael signature.asc Description: This is a digitally signed message part. ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Compile dir detection
On Fri, Mar 20, 2009 at 12:23 AM, Nick Matteo wrote: > I am not sure about the necessity for the 'dir' argument in Recipes. > Right now, I am trying to update the Foomatic recipe for 4.0, and it > has a mess in it about figuring out what the $dir should be. > > It would seem reasonable to examine the archive file to find out where > the files will be unpacked, and just set $dir to that; and if there's > more than one top-level name, create a dir and unpack inside it. Are > there any problems with this approach? There are various projects which offer a tarball which have more than just the code we want to compile. Take SquashFS-Tools and MTD-Utils for example, for which we only care about their "squashfs-tools" and "utils" subdirectories, respectively. We can make no assumptions on the (sub)directory which holds the compilation scripts. Lucas ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
