* configure/make/make install with moving srcdir, builddir...
@ 2002-07-03 16:15 Nathanael Nerode
2002-07-04 0:19 ` Mark Mitchell
0 siblings, 1 reply; 7+ messages in thread
From: Nathanael Nerode @ 2002-07-03 16:15 UTC (permalink / raw)
To: gcc, binutils, gdb
OK. I've figured out a relatively efficient way to handle *most* of the
cases of 'configure', 'make', and 'make install' being done in different
paths.
There's one case this *can't* handle. The specification of
${srcdir} must not change from configure time to make time to
'make install' time. In other words, you can't pass a totally different
srcdir on the 'make' command line and expect it to work.
Is this acceptable, or should I try to get this case?
--Nathanael
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: configure/make/make install with moving srcdir, builddir...
2002-07-03 16:15 configure/make/make install with moving srcdir, builddir Nathanael Nerode
@ 2002-07-04 0:19 ` Mark Mitchell
2002-07-04 9:36 ` DJ Delorie
0 siblings, 1 reply; 7+ messages in thread
From: Mark Mitchell @ 2002-07-04 0:19 UTC (permalink / raw)
To: Nathanael Nerode, gcc, binutils, gdb
--On Wednesday, July 03, 2002 07:13:57 PM -0400 Nathanael Nerode
<neroden@doctormoo.dyndns.org> wrote:
> OK. I've figured out a relatively efficient way to handle *most* of the
> cases of 'configure', 'make', and 'make install' being done in different
> paths.
>
> There's one case this *can't* handle. The specification of
> ${srcdir} must not change from configure time to make time to
> 'make install' time. In other words, you can't pass a totally different
> srcdir on the 'make' command line and expect it to work.
>
> Is this acceptable, or should I try to get this case?
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.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: configure/make/make install with moving srcdir, builddir...
2002-07-04 0:19 ` Mark Mitchell
@ 2002-07-04 9:36 ` DJ Delorie
2002-07-04 10:19 ` Mark Mitchell
0 siblings, 1 reply; 7+ messages in thread
From: DJ Delorie @ 2002-07-04 9:36 UTC (permalink / raw)
To: mark; +Cc: neroden, gcc, binutils, gdb
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: configure/make/make install with moving srcdir, builddir...
2002-07-04 9:36 ` DJ Delorie
@ 2002-07-04 10:19 ` Mark Mitchell
2002-07-04 14:20 ` Geoff Keating
2002-07-04 16:34 ` DJ Delorie
0 siblings, 2 replies; 7+ messages in thread
From: Mark Mitchell @ 2002-07-04 10:19 UTC (permalink / raw)
To: DJ Delorie; +Cc: neroden, gcc, binutils, gdb
--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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: configure/make/make install with moving srcdir, builddir...
2002-07-04 10:19 ` Mark Mitchell
@ 2002-07-04 14:20 ` Geoff Keating
2002-07-05 9:45 ` Mark Mitchell
2002-07-04 16:34 ` DJ Delorie
1 sibling, 1 reply; 7+ messages in thread
From: Geoff Keating @ 2002-07-04 14:20 UTC (permalink / raw)
To: mark; +Cc: dj, neroden, gcc, binutils, gdb
> Date: Thu, 04 Jul 2002 10:18:11 -0700
> From: Mark Mitchell <mark@codesourcery.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.
...
It may be that it's easier to replace this usage with another
convenient way to do things. For instance, GCC is supposed to be
location-independent; perhaps we could ask that people who would use
'make install' to install on multiple machines in different places
instead use the (well-tested and often-used) facilities to install in
an alternative directory, and then use 'tar' or a package management
tool to move the binaries to where they need to go.
It's arguable that really, GCC's makefiles shouldn't be dealing with
many of these things at all (like uninstalling or installing over an
earlier version); it's better to delegate them to a real
package-management system.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: configure/make/make install with moving srcdir, builddir...
2002-07-04 14:20 ` Geoff Keating
@ 2002-07-05 9:45 ` Mark Mitchell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2002-07-05 9:45 UTC (permalink / raw)
To: Geoff Keating; +Cc: dj, neroden, gcc, binutils, gdb
--On Thursday, July 04, 2002 02:20:29 PM -0700 Geoff Keating
<geoffk@geoffk.org> wrote:
>> Date: Thu, 04 Jul 2002 10:18:11 -0700
>> From: Mark Mitchell <mark@codesourcery.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.
> ...
>
> It may be that it's easier to replace this usage with another
> convenient way to do things. For instance, GCC is supposed to be
> location-independent; perhaps we could ask that people who would use
> 'make install' to install on multiple machines in different places
> instead use the (well-tested and often-used) facilities to install in
> an alternative directory, and then use 'tar' or a package management
> tool to move the binaries to where they need to go.
That's a possibility as well.
In either case, we agree that we don't need this facility in the new
Makefiles before we check them in.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: configure/make/make install with moving srcdir, builddir...
2002-07-04 10:19 ` Mark Mitchell
2002-07-04 14:20 ` Geoff Keating
@ 2002-07-04 16:34 ` DJ Delorie
1 sibling, 0 replies; 7+ messages in thread
From: DJ Delorie @ 2002-07-04 16:34 UTC (permalink / raw)
To: mark; +Cc: neroden, gcc, binutils, gdb
> 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 agree somewhat. IMHO it's important to at least think about all the
features, so we don't *inadvertently* disable one. But more important
is to think of what the users are trying to accomplish, and is there
some *other* way they could do that? If so, we have some flexibility
in how to move forward.
So, to me, it's better to say "What about XYZ?" "No, we're dropping
that" than to say "Oops! We forgot about XYZ" later. But better yet
to just support it if it's reasonable to do so.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-07-05 16:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-03 16:15 configure/make/make install with moving srcdir, builddir Nathanael Nerode
2002-07-04 0:19 ` Mark Mitchell
2002-07-04 9:36 ` DJ Delorie
2002-07-04 10:19 ` Mark Mitchell
2002-07-04 14:20 ` Geoff Keating
2002-07-05 9:45 ` Mark Mitchell
2002-07-04 16:34 ` DJ Delorie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox