From: Mark Mitchell <mark@codesourcery.com>
To: DJ Delorie <dj@redhat.com>
Cc: "neroden@doctormoo.dyndns.org" <neroden@doctormoo.dyndns.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
"binutils@sources.redhat.com" <binutils@sources.redhat.com>,
"gdb@sources.redhat.com" <gdb@sources.redhat.com>
Subject: Re: configure/make/make install with moving srcdir, builddir...
Date: Thu, 04 Jul 2002 10:19:00 -0000 [thread overview]
Message-ID: <61310000.1025803091@warlock.codesourcery.com> (raw)
In-Reply-To: <200207041636.g64GacS06439@greed.delorie.com>
--On Thursday, July 04, 2002 12:36:38 PM -0400 DJ Delorie <dj@redhat.com>
wrote:
>
>> I think that's fine. And if we can really simplify our makefiles that's
>> worth more than being able to change the $srcdir around. We can always
>> add that later if someone really, really needs it.
>
> What about the case where you do a build on one machine, and do "make
> install" on many others with different mount points? Doesn't that
> need to know where srcdir is, yet srcdir is a different location for
> them?
Yes -- but this is exactly the kind of thing that I think we can live
without.
I know people do this; I know it's convenient.
This is a special case of a general problem we have with GCC. There are
some processes we have that we know are hard to maintain and error-prone
(build is one, test is another). On the other hand, over the years, we've
beaten on these issues to the point where there's support for lots and lots
of somewhat obscure usages.
In order to make progress, we know we can't make an incremental change;
we need to make a drastic change. (In this case, autoconfiscation.) But,
it's hard to do that and preserve every last feature of the old system,
all at once. (For one thing, the compiler keeps changing as you go.)
I think we willing to say "Yes, autoconfiscation is good; yes, that hits
the common cases; yes that will reduce our overall development burden.
Do it!" And then the (relatively few) people who do "make install" onto
a bunch of machines can come back and agitate later to add that feature
back.
The feature is a good one; I just don't think we shouldn't set the bar too
high.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
next prev parent reply other threads:[~2002-07-04 17:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-03 16:15 Nathanael Nerode
2002-07-04 0:19 ` Mark Mitchell
2002-07-04 9:36 ` DJ Delorie
2002-07-04 10:19 ` Mark Mitchell [this message]
2002-07-04 14:20 ` Geoff Keating
2002-07-05 9:45 ` Mark Mitchell
2002-07-04 16:34 ` DJ Delorie
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=61310000.1025803091@warlock.codesourcery.com \
--to=mark@codesourcery.com \
--cc=binutils@sources.redhat.com \
--cc=dj@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=neroden@doctormoo.dyndns.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