Guido Draheim wrote: > ... we do not > need any automake support when a staging area (a > chroot-like target host simulation-filetree) is > being used, it would just be a different DESTDIR, > and it would also provide the support for any > other build support file, like includeheaders or > some other modules, one could even use a binary > package for the target host, and install under > a reloc-prefix. > > That gives a good future compatibility as we do not > need to know anymore which of the files need a > copy on the build host (if in doubt, install them > all), and there is just one problem left - where > is the staging area, and how is the fhs being > used in there. That is sure no easy answer. The > print-search-dirs scheme migh help, but I didn't > come to any conclusive so far.
IMHO we tell the compiler and linker about the staging area through -I and -L arguments. Libtool supports those just fine, I think; we just have to make sure that they are available to libtool (and here's where automake might need to get involved a bit). By the way, this doesn't solve my original concern, which was 'When building somebody else's fully autoconf/automake/libtoolized package, how do I avoid installing static libraries on my embedded system?' But I suppose I can just globally remove all .a files in the image I copy from the staging area... - Dan
