RE: Final toolchain dir

[ANDY KENNEDY <ANDY dot KENNEDY at adtran dot com>]

> I have an option here, that implies some union mounts, and can ease
> the
> stuff (absolutely untested, product of my insane brain!), but that
> does
> not cover the SDK case you and Javier need to handle:
> 
> - create a directory that will be used to _hold_ the staging area
> - create another directory, that will be used _as_ the staging area
> - union mount the sysroot as a RO branch and the real staging area
>   (ie the first created dir above) as a RW branch onto the final
>   staging area (the second dir created above).
> - rename all the toolchain tools (eg. tuple-gcc, tuple-g++, tuple-
> ld
>   and so on...) and provide wrappers to replace them
> - have the wrapper always include --sysroot=/the/union/mount/point
> - use /the/union/mount/point as DESTDIR when installing
> - once eveything is installed, unmount the union, and use the real
>   staging area (the first dir created above) as the source for
>   populate
> - use populate as previously explained.
> 
> That way, you ensure that:
> - the sysroot is not poluted with secondary libs (eg. zlib, Qt...)
> - the apps always find the system libs *and* the secondary system
> libs
>   thanks to the --sysroot option forced by the wrappers
> - the target directory does not contain headers and static stuff
> from
>   the sysroot
> 
> However:
> - you have to cleanup the real staging area of the headers and
> static libs
>   and other stuff that have no say in the target file system

If I ever start drinking I may read this again to see if it makes
sense to me then.  For now, however, I think I'll continue to do it
the wrong way as I tend to be lazy, find the easiest way out, and
that seems really script code involved ;).

Andy


--
For unsubscribe information see http://sourceware.org/lists.html#faq