Re: [PATCH] top-level configure: setup target_configdirs based on repository

[Thomas Schwinge <thomas@codesourcery.com>]

Hi!

I only had a curious look here; hope that's still useful.

On 2021-09-22T16:30:42+0100, Andrew Burgess <andrew.burgess@embecosm.com> wrote:
> The top-level configure script is shared between the gcc repository
> and the binutils-gdb repository.
>
> The target_configdirs variable in the configure.ac script, defines
> sub-directories that contain components that should be built for the
> target using the target tools.
>
> Some components, e.g. zlib, are built as both host and target
> libraries.
>
> This causes problems for binutils-gdb.  If we run 'make all' in the
> binutils-gdb repository we end up trying to build a target version of
> the zlib library, which requires the target compiler be available.
> Often the target compiler isn't immediately available, and so the
> build fails.

I did wonder: shouldn't normally these target libraries be masked out via
'noconfigdirs' (see 'Handle --disable-<component> generically' section),
via 'enable_[...]' being set to 'no'?  But I think I now see the problem
here: the 'enable_[...]' variables guard both the host and target library
build!  (... if I'm quickly understanding that correctly...)

... and you do need the host zlib, thus '$enable_zlib != no'.

> The problem with zlib impacted a previous attempt to synchronise the
> top-level configure scripts from gcc to binutils-gdb, see this thread:
>
>   https://sourceware.org/pipermail/binutils/2019-May/107094.html
>
> And I'm in the process of importing libbacktrace in to binutils-gdb,
> which is also a host and target library, and triggers the same issues.
>
> I believe that for binutils-gdb, at least at the moment, there are no
> target libraries that we need to build.
>
> My proposal then is to make the value of target_libraries change based
> on which repository we are building in.  Specifically, if the source
> tree has a gcc/ directory then we should set the target_libraries
> variable, otherwise this variable is left entry.
>
> I think that if someone tries to create a single unified tree (gcc +
> binutils-gdb in a single source tree) and then build, this change will
> not have a negative impact, the tree still has gcc/ so we'd expect the
> target compiler to be built, which means building the target_libraries
> should work just fine.
>
> However, if the source tree lacks gcc/ then we assume the target
> compiler isn't built/available, and so target_libraries shouldn't be
> built.
>
> There is already precedent within configure.ac for check on the
> existence of gcc/ in the source tree, see the handling of
> -enable-werror around line 3658.

(I understand that one to just guard the 'cat $srcdir/gcc/DEV-PHASE',
tough.)

> I've tested a build of gcc on x86-64, and the same set of target
> libraries still seem to get built.  On binutils-gdb this change
> resolves the issues with 'make all'.
>
> Any thoughts?

> --- a/configure.ac
> +++ b/configure.ac
> @@ -180,9 +180,17 @@ target_tools="target-rda"
>  ## We assign ${configdirs} this way to remove all embedded newlines.  This
>  ## is important because configure will choke if they ever get through.
>  ## ${configdirs} is directories we build using the host tools.
> -## ${target_configdirs} is directories we build using the target tools.
> +##
> +## ${target_configdirs} is directories we build using the target
> +## tools, these are only needed when working in the gcc tree.  This
> +## file is also reused in the binutils-gdb tree, where building any
> +## target stuff doesn't make sense.
>  configdirs=`echo ${host_libs} ${host_tools}`
> -target_configdirs=`echo ${target_libraries} ${target_tools}`
> +if test -d ${srcdir}/gcc; then
> +  target_configdirs=`echo ${target_libraries} ${target_tools}`
> +else
> +  target_configdirs=""
> +fi
>  build_configdirs=`echo ${build_libs} ${build_tools}`

What I see is that after this, there are still occasions where inside
'case "${target}"', 'target_configdirs' gets amended, so those won't be
caught by your approach?

Instead of erasing 'target_configdirs' as you've posted, and
understanding that we can't just instead add all the "offending" ones to
'noconfigdirs' for '! test -d "$srcdir"/gcc/' (because that would also
disable them for host usage), I wonder if it'd make sense to turn all
existing 'target_libraries=[...]' and 'target_tools=[...]' assignments
and later amendments into '[...]_gcc=[...]' variants, with potentially
further variants existing -- but probably not, because won't you always
need the target GCC to be able to build target libraries ;-) -- and then,
where we finally evalue '$target_libraries' and '$target_tools', only
evaluate the '[...]_gcc' variants iff 'test -d "$srcdir"/gcc/'?

(All that completely untested, of course...)


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955