Hi all,
(no need to CC me, I just subscribed to the list)
TL;DR
I'm seeking advice for a project that involves software on a "normal"
(x86/x86_64/arm) and a cross-compiled (here: AVR microcontroller, but it
could be any other) platform.
How to correctly handle a cross-compiled subproject in autoconf/-tools?
My project roughly looks like the following:
.
├── configure.ac
├── Makefile.am
├── cross-su
│ ├── configure.ac
│ ├── configure.gnu
│ ├── Makefile.am
│ └── firmware.c
├── src
│ ├── Makefile.am
│ └── hello.c
└── ...
There is software to be run on the build system in src/ and there is
software in cross-sub/ that needs to be cross-compiled. Both parts work
together/depend on each other so it makes sense to have them in the same
project. This has the advantage to just have to run
./configure && make && make install
or
make dist
and one gets everything needed.
As far as I understand the autotools, one project is meant to be built
for one platform. Therefore, the cross-compiled part in this example is
an independent autotools project with separate `configure.ac' and
`Makefile.am'.
Using AC_CONFIG_SUBDIRS([cross-sub]) [0] in the upper `configure.ac'
allows us to call the subproject's configure script.
This is correctly done by the various tools like autoreconf, configure,
make...
However, when using AC_CONFIG_SUBDIRS it is not possible to change the
`configure' parameters (like --host=avr) for the subproject, thus, I use
a hack already mentioned in [1] by having a `configure.gnu' wrapper.
The `configure.gnu' file is called by the upper `configure' script
instead of the normal subproject's `configure'.
In the `configure.gnu' I then call `./configure' with `--host=avr' and
some other parameters, like a different --prefix or --bindir.
(Likely, I could also write an m4 macro that takes the arguments for the
subproject, but I didn't want to touch m4.)
I can now generate the configure and Makefile.am scripts recursively by
just running
autoreconf -vi
and then
mkdir build && cd build/ && ../configure && make
and everything is checked and compiled correctly, for instance the use
of 'gcc' and 'avr-gcc' dependent on the project.
If someone runs `make install' that, too, works fine.
/After this long introduction, finally to the yet unsolved problem/:
When `make install-strip' is run, `make' runs recursively through the
directories and calls
/bin/mkdir -p '/the/install/dir'
STRIPPROG='strip' /bin/bash /to/project/build-aux/install-sh -c -s \
thebinary '/the/install/dir'
This fails for the subproject, because to strip a cross-compiled ELF
file, `$host-strip' (here: avr-strip) would be needed instead of normal
`strip'.
The subproject's Makefile -- correctly -- has a variable
STRIP = avr-strip
in it, and runs all fine when it is built alone.
But when it is called recursively from the upper Makefile this is
overridden via STRIPPROG='strip', which then fails and aborts `make'.
The problem might occur also with other targets, but install-strip was
the one where I noticed it.
Is there a fix to this, how can this behaviour be avoided?
Is there a more generic/universal way to handle subprojects that need to
be cross-compiled?
How can I make sure that no environment variables and parameters
"pollute"/override those in the subproject?
I temporarily put online a minimum working example [2] where you can
test this for yourself. In case you don't have the avr-gcc and avr-libc
cross-tools installed and want to try with other cross-tools, simply
replace `--host=avr' in configure.gnu with what you need.
Thanks for reading so much text &
Cheers,
-- panic
[0]
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Subdirectories.html#Subdirectories
[1] https://lists.gnu.org/archive/html/autoconf/2010-01/msg00087.html
[2] https://home.in.tum.de/~benes/mwe/autotools-mwe.tar.xz
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
