public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@wdc.com>
To: Joseph Myers <joseph@codesourcery.com>,
	Ian Lance Taylor <iant@golang.org>
Cc: gcc-patches@gcc.gnu.org, libffi-discuss@sourceware.org,
	    gofrontend-dev@googlegroups.com, zlib@gzip.org
Subject: Re: [PATCH v3] Add `--with-toolexeclibdir=' configuration option
Date: Tue, 21 Jan 2020 02:46:00 -0000	[thread overview]
Message-ID: <alpine.LFD.2.21.2001210234270.15714@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2001210043460.5014@digraph.polyomino.org.uk>

On Tue, 21 Jan 2020, Joseph Myers wrote:

> > Provide means, in the form of a `--with-toolexeclibdir=' configuration 
> > option, to override the default installation directory for target 
> > libraries, otherwise known as $toolexeclibdir.  This is so that it is 
> > possible to get newly-built libraries, particularly the shared ones, 
> > installed in a common place, so that they can be readily used by the 
> > target system as their host libraries, possibly over NFS, without a need 
> > to manually copy them over from the currently hardcoded location they 
> > would otherwise be installed in.
> 
> This patch is OK (I think you'll need to go via Ian for committing the 
> libgo part since that directory is imported from elsewhere).

 Joseph: Thank you for your review.

 Ian: Can we please coordinate this somehow?  The libgo/ part, like all, 
relies on config/toolexeclibdir.m4, so I can either:

1. push the whole change all at once and you'll push the libgo/ part to 
   your repo independently, which shouldn't be an issue except perhaps for 
   policy reasons as the changes will be identical anyway, or

2. push all the bits sans the libgo/ part and you'll push the libgo/ part 
   to your repo and then you'll merge it to GCC.

There is a slight technical advantage to going with #1 as there'll be no 
window where the new option is not consistently supported; it's also less 
work as you won't have to do the merge.  But I have no strong preference 
either way.

  Maciej

  reply	other threads:[~2020-01-21  2:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 14:26 Maciej W. Rozycki
2020-01-21  0:44 ` Joseph Myers
2020-01-21  2:46   ` Maciej W. Rozycki [this message]
2020-01-21  5:07     ` Ian Lance Taylor
2020-01-24 11:27       ` [committed v4] " Maciej W. Rozycki
2020-01-24 14:36         ` Ian Lance Taylor

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=alpine.LFD.2.21.2001210234270.15714@redsun52.ssa.fujisawa.hgst.com \
    --to=macro@wdc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@golang.org \
    --cc=joseph@codesourcery.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=zlib@gzip.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).