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

[Gavin Smith]

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.

>
> For the first point I was able to derive an AC_PROG_BUILD_CC from
> AC_PROG_CC, to probe for a compiler using AC_CHECK_PROG instead of
> AC_CHECK_TOOL, and set BUILD_CC.  That's just a PoC, not sufficient in
> itself, since other tools from the toolchain will be required (and it
> partly duplicates code, which is not nice eiher).  At least it does
> not *require* modificaiton to autoconf in itself, as the macro can be
> embedded into source packages if needed.
>
> For the second point, it would seem a good idea at some point to
> support a "native_" prefix, so setting eg. "native_PROGRAMS" will
> trigger the use of BUILD_* tools.
>

The "noinst_" prefix could be closely related. It would seem that most
of the time you wouldn't want to install these files.

(PS What's PoC? Piece of cake?)

> But as a first step I experimented with setting $program_CC, like can
> be done for flags.  The PoC patch below attempts to do that, and in
> fact setting "gnushogi_CC=$(BUILD_CC)" does produce the expected
> result in Makefile.in (separate rules for gnushogi-*.o are produced,
> with the correct CC being called).

File-specific variables could work. I imagine you are using generic
rules for cross-compilation, and explicit rules for when you are
building your auxiliary tools?

My general advice is to keep rules, flags, variables, etc. used for
building files for one architecture completely separate from those
used for another architecture. Also you have to make sure that you
find all the tools you need.

>
> Where I'm running into problems is that setting CCLD in the same way
> requires further changes (eg. expanding LINK for all targets instead
> of using this as a variable, or overriding LINK instead which looks
> not as clean).
>

I don't know if you saw in the manual that you can set a
target-specific linker? See "maude_LINK" at

http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html#Program-and-Library-Variables

> And without even trying to touch this, I also have
> another problem to deal with, where requesting my native binary
> triggers some sort of default rule attempting to build the binary in
> one step directly from the C source, with the cross-cc and wrong flags.
>

If it is running the wrong rule make sure there is an explicit rule
for the target in the makefile.