public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] top-level configure: setup target_configdirs based on repository
Date: Wed, 22 Sep 2021 16:30:42 +0100	[thread overview]
Message-ID: <20210922153042.3491108-1-andrew.burgess@embecosm.com> (raw)

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.

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'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?

ChangeLog:

	* configure: Regenerate.
	* configure.ac (target_configdirs): Only set this when building
	within the gcc repository.
---
 ChangeLog    |  6 ++++++
 configure    | 12 ++++++++++--
 configure.ac | 12 ++++++++++--
 3 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 85ab9915402..3ef5c2b553f 100755
--- a/configure
+++ b/configure
@@ -2849,9 +2849,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}`
 
 
diff --git a/configure.ac b/configure.ac
index 1df038b04f3..d1217e3f886 100644
--- 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}`
 
 m4_divert_text([PARSE_ARGS],
-- 
2.25.4


             reply	other threads:[~2021-09-22 15:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 15:30 Andrew Burgess [this message]
2021-09-23  8:53 ` Richard Biener
2021-09-24 10:23   ` Andrew Burgess
2021-09-23  9:29 ` Thomas Schwinge
2021-09-24 10:34   ` [PATCHv2] " Andrew Burgess
2021-09-27  7:50     ` Thomas Schwinge
2021-09-27  8:23     ` Richard Biener
2021-09-28  8:45       ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210922153042.3491108-1-andrew.burgess@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).