automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] improving support for building native tools in cross setups


From: Peter Rosin
Subject: Re: [RFC] improving support for building native tools in cross setups
Date: Thu, 30 Jan 2014 23:20:29 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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 <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]