automake-patches
[Top][All Lists]
Advanced

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

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


From: Yann Dirson
Subject: [RFC] improving support for building native tools in cross setups
Date: Wed, 29 Jan 2014 23:40:02 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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:

* autoconf only probes for host CC as soon as cross-compilation is
  required, so we cannot benefit from AC_PROG_CC for detection of the
  build CC
* automake does not distinguish between programs/libs to be built for
  the target or for the build machine

This results in people using various hacks to achieve what should be
IMHO an easy task.


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.

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).

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).  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.


Before diving furthe into this, I thought it would be useful to get
some feedback.


diff --git a/bin/automake.in b/bin/automake.in
index 283d1bb..c4ca471 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1387,6 +1387,12 @@ sub handle_languages ()
                $obj_compile =~ s/\(AM_$flag\)/\($val\)/
                  if set_seen ($val);
              }
+           for my $flag ($lang->ccer, $lang->lder)
+             {
+               my $val = "${derived}_$flag";
+                $obj_compile =~ s/\($flag\)/\($val\)/
+                  if set_seen ($val);
+             }
 
            my $libtool_tag = '';
            if ($lang->libtool_tag && exists $libtool_tags{$lang->libtool_tag})
@@ -1634,6 +1640,8 @@ sub handle_single_transform
            my $have_per_exec_flags = 0;
            my @peflags = @{$lang->flags};
            push @peflags, 'LIBTOOLFLAGS' if $obj eq '.lo';
+           push @peflags, $lang->ccer if defined $lang->ccer;
+           push @peflags, $lang->lder if defined $lang->lder;
            foreach my $flag (@peflags)
              {
                if (set_seen ("${derived}_$flag"))



reply via email to

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