This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: the mechanics of unpacking the source for a toolchain


Robert P. J. Day wrote:
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.

Yes, except for maybe zip, and certainly not RPM. Who uses zip who's serious about gcc?

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

Assume it's already patched. This will be the case if you're using CVS, say. Any patches you still need, you should apply to your local tree (and scream bloody murder until they make it into the CVS tree :-)

I don't like the idea of using hard links and patching
the 'copy' of the source tree too much.  It's clever, but
fragile, and it doesn't seem to be something that would
be commonly needed.
- Dan

--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]