the mechanics of unpacking the source for a toolchain

["Robert P. J. Day" <rpjday at mindspring dot com>]

  as part of my thoughts on unpacking (and patching) the source
for the toolchain components, i was allowing for the possibility
of each of the components being stored in a different format --
gzipped tarball, bzip2 tarball, zip file, or RPM -- and the 
unpack function would be responsible for handling all of these
formats and unloading them into a build directory for patching
and further processing.  so far, so good.

  but what about any of those components already existing in 
an exploded directory (good example -- kernel source.)  what do 
you do then?

  well, if the location variable points to a directory, i guess
you really have no choice but to assume that that directory
represents properly pristine, unpatched source and take it from
there.

  normally, since you're going to have to patch any of these
sources in the process of building the toolchain, you'd first
have to make an entire copy of the directory, as you wouldn't 
want to patch the original directory.  this is safe, but it's 
horrendously expensive in terms of using extra space.  but there's
a better way.

  if you have the original directory, call it source/, all you
have to do is make a recursive copy with hard links:

  $ cp -al source source.crosstool

note that this takes up almost *no* extra space since the new
directory consists entirely of nothing but hard links.  cheap
and really fast.  now use "patch" to apply the patches to the
new directory.

  "patch" has the wonderful property that it makes a new copy
of each patched file, breaking the hard link before making the
changes.  so the only space you'll need is the extra space for
only those files that are changed.  cool.

  the obvious caution is that, since you'll still be referring to
the original unchanged files, you really want to make sure no one's
messing with them as you're running crosstool.  the safe thing,
of course, is to just copy the entire directory.  but if you're
into saving space, the hard links approach is worth thinking about.

rday



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com