On 09/11/2018 15:07, Alexandre Oliva wrote:
> Richard,
> 
> Olivier tells me he talked to you briefly at the Cauldron about allowing
> custom multilib sets to be configured from custom Makefile fragments
> supplied at configure time, and that you was somewhat receptive to the
> idea.  I have implemented this as follows, for ARM targets only so far,
> using "@/path/name" in the argument to --with-multilib-list to mean
> /path/name is to be used as a multilib-list Makefile fragment.
> 
> Does this look like an acceptable interface?  Is it ok as far as ARM
> maintainers are concerned?
> 
> Any objections from maintainers of other targets that support
> --with-multilib-list (or from anyone else) to the syntax, to the
> implementation, or to extending this possibility to their ports?
> 
> for  gcc/ChangeLog
> 
>       * config.gcc (tmake_file): Add /path/name to tmake_file for
>         each @/path/name in --with-multilib-list on arm-*-* targets.
>       * configure.ac: Accept full pathnames in tmake_file.
>       * configure: Rebuilt.
>       * doc/install.texi (with-multilib-list): Document it.

I'm not opposed to such an extension, but I do have some caveats on the
current implementation (mostly on the implied contract between the
compiler and the person building GCC):

- I'm not sure if we really want to allow combinations of an arbitrary
multilib config with the builtin configurations.  Those are tricky
enough to get right as it is, and requests to support additional libs as
well as those with changes to these makefile fragments might be an
issue.  As such, I think I'd want to say that you either use the builtin
lists *or* you supply your own fragment.

- I'd also be concerned about implying that this interface into the
compiler build system is in any way stable, so I think we'd want to
document explicitly that makefile fragments supplied this way may have
to be tailored to a specific release of GCC.

Given the second point, there's nothing to stop a user copying the
internal makefile fragments into their own fragment and then adjusting
it to work with their additional features; so I don't think the first
restriction is too onerous.

R.

> ---
>  gcc/config.gcc       |   13 +++++++++++++
>  gcc/configure        |    9 ++++++---
>  gcc/configure.ac     |    5 ++++-
>  gcc/doc/install.texi |   22 +++++++++++++++-------
>  4 files changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 7578ff03825e..f1363c41f989 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3998,6 +3998,19 @@ case "${target}" in
>                                       aprofile|rmprofile)
>                                               
> tmake_profile_file="arm/t-multilib"
>                                               ;;
> +                                     @/*)
> +                                             ml=`echo "X$arm_multilib" | sed 
> '1s,^X@,,'`
> +                                             if test -f "${ml}"; then
> +                                                     
> tmake_file="${tmake_file} ${ml}"
> +                                             else
> +                                                     echo "Error: ${ml} does 
> not exist" >&2
> +                                                     exit 1
> +                                             fi
> +                                             ;;
> +                                     @*)
> +                                             echo "Error: multilib config 
> file must start with /" >&2
> +                                             exit 1
> +                                             ;;
>                                       *)
>                                               echo "Error: 
> --with-multilib-list=${with_multilib_list} not supported." 1>&2
>                                               exit 1
> diff --git a/gcc/configure b/gcc/configure
> index b814484ea25b..5f15c7a1ff02 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -12244,7 +12244,10 @@ done
>  tmake_file_=
>  for f in ${tmake_file}
>  do
> -     if test -f ${srcdir}/config/$f
> +     if test -n `echo "X$f" | sed -n '1s,^X/.*,/,p` && test -f "$f"
> +     then
> +             tmake_file_="${tmake_file_} $f"
> +     elif test -f ${srcdir}/config/$f
>       then
>               tmake_file_="${tmake_file_} \$(srcdir)/config/$f"
>       fi
> @@ -18572,7 +18575,7 @@ else
>    lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>    lt_status=$lt_dlunknown
>    cat > conftest.$ac_ext <<_LT_EOF
> -#line 18575 "configure"
> +#line 18578 "configure"
>  #include "confdefs.h"
>  
>  #if HAVE_DLFCN_H
> @@ -18678,7 +18681,7 @@ else
>    lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>    lt_status=$lt_dlunknown
>    cat > conftest.$ac_ext <<_LT_EOF
> -#line 18681 "configure"
> +#line 18684 "configure"
>  #include "confdefs.h"
>  
>  #if HAVE_DLFCN_H
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 59585912556b..99a3e6f8f52f 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -1940,7 +1940,10 @@ done
>  tmake_file_=
>  for f in ${tmake_file}
>  do
> -     if test -f ${srcdir}/config/$f
> +     if test -n `echo "X$f" | sed -n '1s,^X/.*,/,p` && test -f "$f"
> +     then
> +             tmake_file_="${tmake_file_} $f"
> +     elif test -f ${srcdir}/config/$f
>       then
>               tmake_file_="${tmake_file_} \$(srcdir)/config/$f"
>       fi
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index be9b07b5d23b..fd19fc590ec8 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -1078,13 +1078,21 @@ values and meaning for each target is given below.
>  
>  @table @code
>  @item arm*-*-*
> -@var{list} is a comma separated list of @code{aprofile} and @code{rmprofile}
> -to build multilibs for A or R and M architecture profiles respectively.  Note
> -that, due to some limitation of the current multilib framework, using the
> -combined @code{aprofile,rmprofile} multilibs selects in some cases a less
> -optimal multilib than when using the multilib profile for the architecture
> -targetted.  The special value @code{default} is also accepted and is 
> equivalent
> -to omitting the option, ie. only the default run-time library will be 
> enabled.
> +@var{list} is a comma separated list of @code{aprofile} and
> +@code{rmprofile} to build multilibs for A or R and M architecture
> +profiles respectively.  Note that, due to some limitation of the current
> +multilib framework, using the combined @code{aprofile,rmprofile}
> +multilibs selects in some cases a less optimal multilib than when using
> +the multilib profile for the architecture targetted.  The special value
> +@code{default} is also accepted and is equivalent to omitting the
> +option, ie. only the default run-time library will be enabled.
> +
> +@var{list} may also contain @code{@@/path/name}, to use the multilib
> +configuration Makefile fragment @file{/path/name}.  Such files enable
> +custom, user-chosen multilib lists to be configured.  Whether multiple
> +such files can be used together depends on the contents of the supplied
> +files.  See @file{gcc/config/arm/t-*profile} for examples of what such
> +Makefile fragments ought to look like.
>  
>  The table below gives the combination of ISAs, architectures, FPUs and
>  floating-point ABIs for which multilibs are built for each accepted value.
> 

Reply via email to