On 2014-01-30 21:53, Yann Dirson wrote: > On Thu, Jan 30, 2014 at 01:33:17PM +0000, Gavin Smith wrote: >> On Wed, Jan 29, 2014 at 10:40 PM, Yann Dirson <ydir...@free.fr> wrote: >>> Hello, >>> >>> It is not uncommon for software packages to build tools to be executed >>> at build time, to generate data files or more input files to compile. >>> >>> Unless I miss something, the current autotools does not help much >>> dealing with this for cross-compilation: >>> >> >> (Link to discussion on other mailing list for reference: >> http://lists.gnu.org/archive/html/automake/2014-01/msg00006.html.) >> Using hand-written rules for these data files and tools with >> AX_CC_FOR_BUILD is a solution if the tools are written in C. If that >> works, even though it needs hand-written rules, unless this is a >> common problem it's probably better to do that then complicate the >> autotools (unless the extra features definitely won't get in the way >> when they're not being used), given that at present it's assumed that >> all files are being built for the same architecture. It would have to >> be thoroughly thought out and tested. > > The problem is widespread enough, that tools like scratchbox > (http://scratchbox.org/) have been created, to workaround deficient > build systems by running such tools emulated by qemu. Clever hack, I > admit, but a huge waste of resources. A well-thought solution > directly integrated in the build system will be cleaner. > > AX_CC_FOR_BUILD, AX_PROG_CXX_FOR_BUILD and such are still IMHO in the > realm of workarounds: for proper support we'll need to write one such > macro for each supported language, and for various binutils, > essentially cut'n'pasting the existing ones. Finding a clean way to
I predict that it is going to be hard to get Libtool to work for two different arches in parallel. But I guess it would be an extreme corner-case to need shared libs when building some extra tools for $build, so it's probably not a biggie. But I'd thought I'd mentioned it... Cheers, Peter