Hello,
the current multilibs support code is a bit racy, in a few ways. The
following might be a bit technical, but I'm trying to gauge where to go
from here, even if this is not fixed right away.
gcc/config/multi.m4 provides AM_ENABLE_MULTILIB which allows to specify
the Makefile which is to be multilibbed. The macro adds another config
command (through obsolete AC_CONFIG_COMMANDS) to config.status.
Autoconf names the command tag 'default-N' with N the index of
additional commands (that usually comes out as 1 or 2). Now, that means
./config.status
or
./config.status some/Makefile default-N
run in some target library build directory, will update some/Makefile
properly (including the multilib adjustments), but
./config.status some/Makefile
will not (and that latter command can be triggered by 'make' when
$srcdir/some/Makefile.in is newer than some/Makefile). There are a few
more interesting data points:
The AC_CONFIG_FILES API allows to associate with an output file
(some/Makefile) additional commands (e.g., precisely those multilib
commands). However, it is not possible to amend to these commands, or
specify AC_CONFIG_FILES(some/file, , additional-commands) twice. So
while we could make AM_ENABLE_MULTILIB call AC_CONFIG_FILES for the
top Makefile of the library directory, that would require the libraries
to all remove that Makefile from their own AC_CONFIG_FILES list
(and prevent them from using any other extra commands they might want
to use).
It would be nice to have an API that would either
1) allow us to add 'default-N' to the automake rule for regenerating the
Makefile (there's the am__depfiles_maybe hack already, but that's an
internal automake detail) (this would be an Automake task),
2) allow us to add additional commands to an AC_CONFIG_<FOOS> instance
later (this would be an Autoconf task, and it could allow us to
eliminate am__depfiles_maybe in the future),
3) or simply add to multi.m4 an API to provide a macro that itself
instantiated
AC_CONFIG_FILES(some/Makefile,,
multi-lib-commands plus more-user-commands)
for example through
AM_MULTILIB_FILES(some/Makefile, [inputs], [more-user-commands])
The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2). Something like
AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
[more-init-cmds])
but then the order of issuing this and the respective
AC_CONFIG_FILES(some/Makefile)
would be significant. I don't see any way to avoid this.
Cheers,
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
