* Obsolete building in source dir?
@ 2004-09-11 4:06 Giovanni Bajo
2004-09-13 7:34 ` DJ Delorie
0 siblings, 1 reply; 28+ messages in thread
From: Giovanni Bajo @ 2004-09-11 4:06 UTC (permalink / raw)
To: gcc
Hello,
Do we still need to support builds in source directory? It looks like it does
not work anymore not even on primary targets because of recent changes. We
discouraged doing it for a long time already, and no developers probably test
this so it is going to be often (always) broken. Maybe is it time to obsolete
(or forbid) this feature for 4.0.0, by having configure emit an error and exit?
Giovanni Bajo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-11 4:06 Obsolete building in source dir? Giovanni Bajo
@ 2004-09-13 7:34 ` DJ Delorie
2004-09-14 19:21 ` Joe Buck
0 siblings, 1 reply; 28+ messages in thread
From: DJ Delorie @ 2004-09-13 7:34 UTC (permalink / raw)
To: gcc
"Giovanni Bajo" <giovannibajo@libero.it> writes:
> Do we still need to support builds in source directory?
Since every other source package on the planet (it seems) supports
building in the source directory, gcc should too. To do otherwise
would require an SC decision, as it would make gcc incompatible with
everything else.
> It looks like it does not work anymore not even on primary targets
> because of recent changes.
So? Treat it like any other bug. Find out who broke it, and get them
to fix it.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-13 7:34 ` DJ Delorie
@ 2004-09-14 19:21 ` Joe Buck
2004-09-14 19:40 ` Zack Weinberg
2004-09-14 20:08 ` DJ Delorie
0 siblings, 2 replies; 28+ messages in thread
From: Joe Buck @ 2004-09-14 19:21 UTC (permalink / raw)
To: DJ Delorie; +Cc: gcc
On Sun, Sep 12, 2004 at 11:07:12PM -0400, DJ Delorie wrote:
> "Giovanni Bajo" <giovannibajo@libero.it> writes:
> > Do we still need to support builds in source directory?
>
> Since every other source package on the planet (it seems) supports
> building in the source directory, gcc should too. To do otherwise
> would require an SC decision, as it would make gcc incompatible with
> everything else.
The SC cannot force people to submit patches to fix the problem;
building in the source directory has been at least partially broken
for years.
I don't think that this is an SC matter. The SC only has the power to
say no (as in demanding that a patch that breaks functionality not
be accepted), likewise the RM.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 19:21 ` Joe Buck
@ 2004-09-14 19:40 ` Zack Weinberg
2004-09-14 19:59 ` Joseph S. Myers
2004-09-14 20:12 ` DJ Delorie
2004-09-14 20:08 ` DJ Delorie
1 sibling, 2 replies; 28+ messages in thread
From: Zack Weinberg @ 2004-09-14 19:40 UTC (permalink / raw)
To: Joe Buck; +Cc: DJ Delorie, gcc
Joe Buck <Joe.Buck@synopsys.COM> writes:
> On Sun, Sep 12, 2004 at 11:07:12PM -0400, DJ Delorie wrote:
>> "Giovanni Bajo" <giovannibajo@libero.it> writes:
>> > Do we still need to support builds in source directory?
>>
>> Since every other source package on the planet (it seems) supports
>> building in the source directory, gcc should too. To do otherwise
>> would require an SC decision, as it would make gcc incompatible with
>> everything else.
>
> The SC cannot force people to submit patches to fix the problem;
> building in the source directory has been at least partially broken
> for years.
Could someone remind me what was wrong with the "if configure notices
it's been invoked in the source directory, create a build directory
behind the user's back" idea? That wouldn't break all the time.
zw
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 19:40 ` Zack Weinberg
@ 2004-09-14 19:59 ` Joseph S. Myers
2004-09-14 20:12 ` DJ Delorie
1 sibling, 0 replies; 28+ messages in thread
From: Joseph S. Myers @ 2004-09-14 19:59 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Joe Buck, DJ Delorie, gcc
On Tue, 14 Sep 2004, Zack Weinberg wrote:
> Could someone remind me what was wrong with the "if configure notices
> it's been invoked in the source directory, create a build directory
> behind the user's back" idea? That wouldn't break all the time.
http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01540.html
has that patch and subsequent discussion leading to its reversion.
I'd be happy with both doing that again and converting relative srcdir to
an absolute path unconditionally to get rid of bugs such as 13993 and
reduce the number of variations Makefiles need to handle to one (building
out of srcdir with an absolute path to srcdir).
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
jsm@polyomino.org.uk (personal mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 19:21 ` Joe Buck
2004-09-14 19:40 ` Zack Weinberg
@ 2004-09-14 20:08 ` DJ Delorie
2004-09-14 20:18 ` Joe Buck
[not found] ` <mailman.80195.1095191985.18468.gnu-gcc@lists.nsr.labs.mot.com>
1 sibling, 2 replies; 28+ messages in thread
From: DJ Delorie @ 2004-09-14 20:08 UTC (permalink / raw)
To: Joe.Buck; +Cc: gcc
> > Since every other source package on the planet (it seems) supports
> > building in the source directory, gcc should too. To do otherwise
> > would require an SC decision, as it would make gcc incompatible with
> > everything else.
>
> The SC cannot force people to submit patches to fix the problem;
> building in the source directory has been at least partially broken
> for years.
The SC decision is "do we *want* to support building in srcdir, or
should we reject such attempts?" Once we know what the SC wants, we
can find someone to make the changes (probably me).
There are a few of us who actively fix build-in-src bugs, mostly
because we feel it's important to act like other GNU packages, but we
can stop feeling that way if the SC deems it so.
> I don't think that this is an SC matter. The SC only has the power to
> say no (as in demanding that a patch that breaks functionality not
> be accepted), likewise the RM.
I think it's appropriate for the SC to get past the political issue of
*wanting* to support it or not. It's somewhat controversial (based on
historical arguments about it) whether the effort spent on maintaining
it is worth it.
Last time I worked on it, I think there was one libfoo directory that
still needed a tweak; libiberty builds in srcdir just fine, and only
directories that get built more than once are of concern anyway.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 19:40 ` Zack Weinberg
2004-09-14 19:59 ` Joseph S. Myers
@ 2004-09-14 20:12 ` DJ Delorie
2004-09-14 21:25 ` Zack Weinberg
` (3 more replies)
1 sibling, 4 replies; 28+ messages in thread
From: DJ Delorie @ 2004-09-14 20:12 UTC (permalink / raw)
To: zack; +Cc: gcc
> Could someone remind me what was wrong with the "if configure
> notices it's been invoked in the source directory, create a build
> directory behind the user's back" idea? That wouldn't break all the
> time.
It's the "behind the user's back" that's a problem. I think that we
should either make it do what the user expected, or tell the user they
can't do that, but to do something the user doesn't expect is bad.
Plus, the toplevel stuff is shared among many projects, and only gcc
has a problem with building in srcdir.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 20:08 ` DJ Delorie
@ 2004-09-14 20:18 ` Joe Buck
[not found] ` <mailman.80195.1095191985.18468.gnu-gcc@lists.nsr.labs.mot.com>
1 sibling, 0 replies; 28+ messages in thread
From: Joe Buck @ 2004-09-14 20:18 UTC (permalink / raw)
To: DJ Delorie; +Cc: gcc
On Tue, Sep 14, 2004 at 03:43:51PM -0400, DJ Delorie wrote:
>
> > > Since every other source package on the planet (it seems) supports
> > > building in the source directory, gcc should too. To do otherwise
> > > would require an SC decision, as it would make gcc incompatible with
> > > everything else.
> >
> > The SC cannot force people to submit patches to fix the problem;
> > building in the source directory has been at least partially broken
> > for years.
>
> The SC decision is "do we *want* to support building in srcdir, or
> should we reject such attempts?" Once we know what the SC wants, we
> can find someone to make the changes (probably me).
I would consider it a technical matter, not a big enough issue for the
SC to step in. So s/SC/GWP maintainers/. If folks with the authority
to approve patches like your patches, cool. I'm not intent on using
the SC to browbeat them into it if they consider that too many kludges
are required.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 20:12 ` DJ Delorie
@ 2004-09-14 21:25 ` Zack Weinberg
2004-09-14 22:25 ` DJ Delorie
2004-09-15 11:09 ` Richard Earnshaw
` (2 subsequent siblings)
3 siblings, 1 reply; 28+ messages in thread
From: Zack Weinberg @ 2004-09-14 21:25 UTC (permalink / raw)
To: DJ Delorie; +Cc: gcc
DJ Delorie <dj@redhat.com> writes:
>> Could someone remind me what was wrong with the "if configure
>> notices it's been invoked in the source directory, create a build
>> directory behind the user's back" idea? That wouldn't break all the
>> time.
>
> It's the "behind the user's back" that's a problem. I think that we
> should either make it do what the user expected, or tell the user they
> can't do that, but to do something the user doesn't expect is bad.
Given all the weird stuff we do _anyway_ - invoking subconfigures from
the Makefile instead of the top level configure, building stuff
multiple times with different compilers, etc. etc. - I don't see this
as that much more surprising. Just to be clearly documented.
> Plus, the toplevel stuff is shared among many projects, and only gcc
> has a problem with building in srcdir.
This raises the question of why gcc has the problem and the other
projects don't. I venture to speculate it's because of the bootstrap
logic. If I'm right, then toplevel bootstrap offers a chance to make
it go away (or, turnabout, to spread the problem to more projects).
zw
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 21:25 ` Zack Weinberg
@ 2004-09-14 22:25 ` DJ Delorie
2004-09-26 23:05 ` Marc Espie
0 siblings, 1 reply; 28+ messages in thread
From: DJ Delorie @ 2004-09-14 22:25 UTC (permalink / raw)
To: zack; +Cc: gcc
> This raises the question of why gcc has the problem and the other
> projects don't.
I suspect it's because gcc is the only project where the organization
of the build tree doesn't match the organization of the source tree.
Between host/build/target modules and multilibs, we move stuff around
a lot. Keeping track of where we put it is where we lose the most. I
suspect that making srcdir absolute will fix most of the hard
problems, and we can conditional that on finding gcc in the source
tree.
if [ -d $srcdir/gcc ]
then
srcdir=`cd $srcdir; $PWDCMD`
fi
Similarly for the build directory. The down side is that you can't
move a build any more, but I've found that to be true already.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
[not found] ` <mailman.80195.1095191985.18468.gnu-gcc@lists.nsr.labs.mot.com>
@ 2004-09-15 6:38 ` Loren James Rittle
0 siblings, 0 replies; 28+ messages in thread
From: Loren James Rittle @ 2004-09-15 6:38 UTC (permalink / raw)
To: gcc; +Cc: rittle
> I would consider it a technical matter, not a big enough issue for the
> SC to step in. [...]
Agreed, the documentation already tells users how to get best results.
Those that refuse to read it or believe it, can report a bug when their
build stops half-way through. That is how all bugs, not seen by gcc
developers, are fixed. In any event:
http://people.freebsd.org/~ljrittle/daily-gcc-bootstrap-reports/ref4/STATUS
gcc 3.1 20020513, objdir configuration, gmake, bootstrapped OK
gcc 3.1 20020513, srcdir configuration, gmake, bootstrapped OK
gcc 3.1.1 , objdir configuration, gmake, bootstrapped OK
gcc 3.1.1 , srcdir configuration, gmake, bootstrapped OK
gcc 3.2 20020813, objdir configuration, gmake, bootstrapped OK
gcc 3.2 20020813, srcdir configuration, gmake, bootstrapped OK
gcc 3.2.1 , objdir configuration, gmake, bootstrapped OK
gcc 3.2.1 , srcdir configuration, gmake, bootstrapped OK
gcc 3.2.2 20030129, objdir configuration, gmake, bootstrapped OK
gcc 3.2.2 20030129, srcdir configuration, gmake, bootstrapped OK
gcc 3.3 20030421, srcdir configuration, gmake, bootstrapped OK
gcc 3.3 20030421, objdir configuration, gmake, bootstrapped OK
gcc 3.3 , srcdir configuration, gmake, bootstrapped OK
gcc 3.3 , objdir configuration, gmake, bootstrapped OK
gcc 3.3.1 20030803, srcdir configuration, gmake, bootstrapped OK
gcc 3.3.1 20030803, objdir configuration, gmake, bootstrapped OK
[This testing machine non-functional during 3.3.2 & 3.3.3 & 3.4 release cycles.]
gcc 3.4.1 , srcdir configuration, gmake, bootstrapped OK
gcc 3.4.1 , objdir configuration, gmake, bootstrapped OK
gcc 3.4.2 , srcdir configuration, gmake, bootstrapped OK
gcc 3.4.2 , objdir configuration, gmake, bootstrapped OK
(The dated versions are close to a release.)
I have no idea about the state of mainline but... Once a 4.0.0 branch
is cut and a daily "srcdir configuration" tester is moved to it, I'm
sure we will fix any bugs before the release. If we don't, then I
will propose the needed documentation patch that I always pull out
whenever it is required...
Regards,
Loren
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 20:12 ` DJ Delorie
2004-09-14 21:25 ` Zack Weinberg
@ 2004-09-15 11:09 ` Richard Earnshaw
2004-09-15 15:43 ` DJ Delorie
2004-09-15 21:15 ` Alexandre Oliva
2004-09-16 22:01 ` Matthias B.
3 siblings, 1 reply; 28+ messages in thread
From: Richard Earnshaw @ 2004-09-15 11:09 UTC (permalink / raw)
To: DJ Delorie; +Cc: zack, gcc
On Tue, 2004-09-14 at 20:47, DJ Delorie wrote:
> > Could someone remind me what was wrong with the "if configure
> > notices it's been invoked in the source directory, create a build
> > directory behind the user's back" idea? That wouldn't break all the
> > time.
>
> It's the "behind the user's back" that's a problem. I think that we
> should either make it do what the user expected, or tell the user they
> can't do that, but to do something the user doesn't expect is bad.
If we print out 'creating build directory in <target>-build...
configuring in <target>-build' then it's no-longer 'behind their back'.
R.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-15 11:09 ` Richard Earnshaw
@ 2004-09-15 15:43 ` DJ Delorie
2004-09-15 16:16 ` Richard Earnshaw
0 siblings, 1 reply; 28+ messages in thread
From: DJ Delorie @ 2004-09-15 15:43 UTC (permalink / raw)
To: rearnsha; +Cc: zack, gcc
> If we print out 'creating build directory in <target>-build...
> configuring in <target>-build' then it's no-longer 'behind their back'.
Assuming the user catches that line in the heaping gobs of output
configure produces (especially when builds are automated). Better to
say:
$ ./configure
configure: Please create a separate build directory for builds including gcc.
$
... so that the user KNOWS.
But, I'd prefer to just fix the bugs. That's what we usually do (and
have historically done) when we find them.
I'm amenable to making $srcdir aboslute when it's relative, too. That
should paper over a number of PRs in a relatively harmless way,
breaking only net installs where the mount points differ from machine
to machine (which is a bad practice anyway IMHO).
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-15 15:43 ` DJ Delorie
@ 2004-09-15 16:16 ` Richard Earnshaw
2004-09-15 16:58 ` Phil Edwards
0 siblings, 1 reply; 28+ messages in thread
From: Richard Earnshaw @ 2004-09-15 16:16 UTC (permalink / raw)
To: DJ Delorie; +Cc: zack, gcc
On Wed, 2004-09-15 at 14:08, DJ Delorie wrote:
> > If we print out 'creating build directory in <target>-build...
> > configuring in <target>-build' then it's no-longer 'behind their back'.
>
> Assuming the user catches that line in the heaping gobs of output
> configure produces (especially when builds are automated). Better to
> say:
>
> $ ./configure
> configure: Please create a separate build directory for builds including gcc.
>
> $
>
> ... so that the user KNOWS.
Why does the user have to KNOW this? Why would they care? We don't
assume that they have to know a lot of other things. All they want to
do is build the compiler so they can install it. I haven't seen a
single reason why they should care that this is done in a subdirectory
of the source rather than in the sources themselves.
R.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-15 16:16 ` Richard Earnshaw
@ 2004-09-15 16:58 ` Phil Edwards
0 siblings, 0 replies; 28+ messages in thread
From: Phil Edwards @ 2004-09-15 16:58 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: DJ Delorie, zack, gcc
On Wed, Sep 15, 2004 at 02:28:14PM +0100, Richard Earnshaw wrote:
> On Wed, 2004-09-15 at 14:08, DJ Delorie wrote:
> > > If we print out 'creating build directory in <target>-build...
> > > configuring in <target>-build' then it's no-longer 'behind their back'.
> >
> > Assuming the user catches that line in the heaping gobs of output
> > configure produces (especially when builds are automated). Better to
> > say:
This is a strawman argument.
You are proposing the existence of a user who
- is building a compiler from scratch
- is automating the build (!)
- gives a flying rat's ass about the location of the build directory
but who also
- has never read the installation instructions
- isn't on the mailing lists
- doesn't log the output of configure and
- can't read config.log
I refuse to believe that such a user exists until you provide concrete
evidence.
> Why does the user have to KNOW this? Why would they care? We don't
> assume that they have to know a lot of other things. All they want to
> do is build the compiler so they can install it. I haven't seen a
> single reason why they should care that this is done in a subdirectory
> of the source rather than in the sources themselves.
Ditto. I've never heard any argument why this should matter to the end
user in the slightest.
They don't care that, for example, our source code comments are written in
grammatically proper English. /We/ care. Likewise, changing how in-srcdir
builds work isn't being done for the user's convenience. It's for /us/.
--
<The_Vulture> evilgeek: actually it's <: and :>, <% and %>
<evilgeek> oh, right. digraphs are always happy
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 20:12 ` DJ Delorie
2004-09-14 21:25 ` Zack Weinberg
2004-09-15 11:09 ` Richard Earnshaw
@ 2004-09-15 21:15 ` Alexandre Oliva
2004-09-16 5:59 ` Ralf Corsepius
2004-09-16 22:01 ` Matthias B.
3 siblings, 1 reply; 28+ messages in thread
From: Alexandre Oliva @ 2004-09-15 21:15 UTC (permalink / raw)
To: DJ Delorie; +Cc: zack, gcc
On Sep 14, 2004, DJ Delorie <dj@redhat.com> wrote:
>> Could someone remind me what was wrong with the "if configure
>> notices it's been invoked in the source directory, create a build
>> directory behind the user's back" idea? That wouldn't break all the
>> time.
> It's the "behind the user's back" that's a problem. I think that we
> should either make it do what the user expected, or tell the user they
> can't do that, but to do something the user doesn't expect is bad.
What if we changed the top-level machinery such that, instead of using
a directory such as `gcc' to build GCC for the host, it used say
`host-gcc', just like we use `build-libiberty' for libiberty built for
the build machine? Then nothing would be configured/built in the
source tree, except for the top-level, that isn't sensitive to these
matters.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-15 21:15 ` Alexandre Oliva
@ 2004-09-16 5:59 ` Ralf Corsepius
2004-09-16 16:47 ` DJ Delorie
2004-09-17 16:38 ` Alexandre Oliva
0 siblings, 2 replies; 28+ messages in thread
From: Ralf Corsepius @ 2004-09-16 5:59 UTC (permalink / raw)
To: Alexandre Oliva; +Cc: DJ Delorie, zack, GCC List
On Wed, 2004-09-15 at 22:29, Alexandre Oliva wrote:
> On Sep 14, 2004, DJ Delorie <dj@redhat.com> wrote:
>
> >> Could someone remind me what was wrong with the "if configure
> >> notices it's been invoked in the source directory, create a build
> >> directory behind the user's back" idea? That wouldn't break all the
> >> time.
>
> > It's the "behind the user's back" that's a problem. I think that we
> > should either make it do what the user expected, or tell the user they
> > can't do that, but to do something the user doesn't expect is bad.
>
> What if we changed the top-level machinery such that, instead of using
> a directory such as `gcc' to build GCC for the host, it used say
> `host-gcc', just like we use `build-libiberty' for libiberty built for
> the build machine? Then nothing would be configured/built in the
> source tree, except for the top-level, that isn't sensitive to these
> matters.
Instead of doing this you could consider to systematically using
$host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
no matter if cross-compiling or not.
Ralf
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-16 5:59 ` Ralf Corsepius
@ 2004-09-16 16:47 ` DJ Delorie
2004-09-17 11:08 ` Ralf Corsepius
2004-09-17 16:38 ` Alexandre Oliva
1 sibling, 1 reply; 28+ messages in thread
From: DJ Delorie @ 2004-09-16 16:47 UTC (permalink / raw)
To: rc040203; +Cc: gcc
> Instead of doing this you could consider to systematically using
> $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> no matter if cross-compiling or not.
Except we can't, because the toplevel machinery is shared among many
projects. We have to be careful not to change those without their
permission.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 20:12 ` DJ Delorie
` (2 preceding siblings ...)
2004-09-15 21:15 ` Alexandre Oliva
@ 2004-09-16 22:01 ` Matthias B.
3 siblings, 0 replies; 28+ messages in thread
From: Matthias B. @ 2004-09-16 22:01 UTC (permalink / raw)
To: gcc
On Tue, 14 Sep 2004 15:47:24 -0400 DJ Delorie <dj@redhat.com> wrote:
> It's the "behind the user's back" that's a problem. I think that we
> should either make it do what the user expected, or tell the user they
> can't do that, but to do something the user doesn't expect is bad.
As a user I agree with that argument and I think the easiest solution
would be to do it on the packaging level. Rather than releasing a tarball
like this
gcc-3.4.1/
INSTALL/
boehm-gc/
...
distribute one like this:
gcc-3.4.1/
configure
Makefile
gcc-build/
gcc-src/
INSTALL/
boehm-gc/
...
where configure and Makefile do the obvious thing and cd into gcc-build
before delegating to ../gcc-src/{configure,Makefile}
As I understand it, the desire to support building from srcdir is more
accurately described as a desire to support building from "the directory
created when extracting the tarball" in order to streamline the build
process for users of the release tarballs. The above packaging solution
achieves that without doing anything behind the user's back or interfering
with the GCC build system.
MSB
--
Conform, go crazy, or become an artist.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-16 16:47 ` DJ Delorie
@ 2004-09-17 11:08 ` Ralf Corsepius
2004-09-17 21:12 ` DJ Delorie
0 siblings, 1 reply; 28+ messages in thread
From: Ralf Corsepius @ 2004-09-17 11:08 UTC (permalink / raw)
To: DJ Delorie; +Cc: GCC List
On Thu, 2004-09-16 at 18:38, DJ Delorie wrote:
> > Instead of doing this you could consider to systematically using
> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> > no matter if cross-compiling or not.
>
> Except we can't, because the toplevel machinery is shared among many
> projects. We have to be careful not to change those without their
> permission.
AFAIU, your concern only applies to subpackages which support "native
compilation only". Do such packages exist within the "uberbaum"?
I am aware about fundamental issues with adalib and about potential
issues with tcl/tk based subpackages, nevertheless all of them can be
expected to support VPATH builds, so I don't see that moving their
--srcdir would break building them.
I am aware that some configure scripts and Makefiles apply nasty tricks
such as test'ing for presence of tools in neighboring build-directories.
These checks/tests probably would require to be adapted in some cases.
Ralf
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-16 5:59 ` Ralf Corsepius
2004-09-16 16:47 ` DJ Delorie
@ 2004-09-17 16:38 ` Alexandre Oliva
2004-09-18 15:14 ` Kai Henningsen
1 sibling, 1 reply; 28+ messages in thread
From: Alexandre Oliva @ 2004-09-17 16:38 UTC (permalink / raw)
To: Ralf Corsepius; +Cc: DJ Delorie, zack, GCC List
On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
> Instead of doing this you could consider to systematically using
> $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> no matter if cross-compiling or not.
This wouldn't quite work if we actually need different builds for say
build, host and target, but they're all the same.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-17 11:08 ` Ralf Corsepius
@ 2004-09-17 21:12 ` DJ Delorie
0 siblings, 0 replies; 28+ messages in thread
From: DJ Delorie @ 2004-09-17 21:12 UTC (permalink / raw)
To: rc040203; +Cc: gcc
> > Except we can't, because the toplevel machinery is shared among many
> > projects. We have to be careful not to change those without their
> > permission.
> AFAIU, your concern only applies to subpackages which support "native
> compilation only".
No, it's a policy issue. We can't decide to change the way their
projects work without their agreement.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-17 16:38 ` Alexandre Oliva
@ 2004-09-18 15:14 ` Kai Henningsen
2004-09-18 17:31 ` Alexandre Oliva
0 siblings, 1 reply; 28+ messages in thread
From: Kai Henningsen @ 2004-09-18 15:14 UTC (permalink / raw)
To: gcc
aoliva@redhat.com (Alexandre Oliva) wrote on 17.09.04 in <oru0twubfc.fsf@free.redhat.lsd.ic.unicamp.br>:
> On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
>
> > Instead of doing this you could consider to systematically using
> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> > no matter if cross-compiling or not.
>
> This wouldn't quite work if we actually need different builds for say
> build, host and target, but they're all the same.
That's trivial to fix by using a {host,build,target}- prefix.
MfG Kai
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-18 15:14 ` Kai Henningsen
@ 2004-09-18 17:31 ` Alexandre Oliva
2004-09-19 18:41 ` Kai Henningsen
0 siblings, 1 reply; 28+ messages in thread
From: Alexandre Oliva @ 2004-09-18 17:31 UTC (permalink / raw)
To: Kai Henningsen; +Cc: gcc
On Sep 18, 2004, kaih@khms.westfalen.de (Kai Henningsen) wrote:
> aoliva@redhat.com (Alexandre Oliva) wrote on 17.09.04 in <oru0twubfc.fsf@free.redhat.lsd.ic.unicamp.br>:
>> On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
>>
>> > Instead of doing this you could consider to systematically using
>> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
>> > no matter if cross-compiling or not.
>>
>> This wouldn't quite work if we actually need different builds for say
>> build, host and target, but they're all the same.
> That's trivial to fix by using a {host,build,target}- prefix.
Which brings us back to exactly what I had suggested before Ralf's
counter-proposal :-)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-18 17:31 ` Alexandre Oliva
@ 2004-09-19 18:41 ` Kai Henningsen
2004-09-20 8:51 ` Ralf Corsepius
0 siblings, 1 reply; 28+ messages in thread
From: Kai Henningsen @ 2004-09-19 18:41 UTC (permalink / raw)
To: gcc
aoliva@redhat.com (Alexandre Oliva) wrote on 18.09.04 in <or8yb77c6m.fsf@livre.redhat.lsd.ic.unicamp.br>:
> On Sep 18, 2004, kaih@khms.westfalen.de (Kai Henningsen) wrote:
>
> > aoliva@redhat.com (Alexandre Oliva) wrote on 17.09.04 in
> > <oru0twubfc.fsf@free.redhat.lsd.ic.unicamp.br>:
> >> On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
> >>
> >> > Instead of doing this you could consider to systematically using
> >> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> >> > no matter if cross-compiling or not.
> >>
> >> This wouldn't quite work if we actually need different builds for say
> >> build, host and target, but they're all the same.
>
> > That's trivial to fix by using a {host,build,target}- prefix.
>
> Which brings us back to exactly what I had suggested before Ralf's
> counter-proposal :-)
Wrong. You proposed build-gcc, he proposed $buils(_alias)-gcc, I proposed
build-$build(_alias)-gcc.
MfG Kai
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-19 18:41 ` Kai Henningsen
@ 2004-09-20 8:51 ` Ralf Corsepius
0 siblings, 0 replies; 28+ messages in thread
From: Ralf Corsepius @ 2004-09-20 8:51 UTC (permalink / raw)
To: GCC List
On Sun, 2004-09-19 at 14:01, Kai Henningsen wrote:
> aoliva@redhat.com (Alexandre Oliva) wrote on 18.09.04 in <or8yb77c6m.fsf@livre.redhat.lsd.ic.unicamp.br>:
>
> > On Sep 18, 2004, kaih@khms.westfalen.de (Kai Henningsen) wrote:
> >
> > > aoliva@redhat.com (Alexandre Oliva) wrote on 17.09.04 in
> > > <oru0twubfc.fsf@free.redhat.lsd.ic.unicamp.br>:
> > >> On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
> > >>
> > >> > Instead of doing this you could consider to systematically using
> > >> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> > >> > no matter if cross-compiling or not.
> > >>
> > >> This wouldn't quite work if we actually need different builds for say
> > >> build, host and target, but they're all the same.
> >
> > > That's trivial to fix by using a {host,build,target}- prefix.
> >
> > Which brings us back to exactly what I had suggested before Ralf's
> > counter-proposal :-)
>
> Wrong. You proposed build-gcc, he proposed $buils(_alias)-gcc,
No, I proposed
$({build|host|target})/<subpackage>
or
$({build|host|target}_alias)/<subpackage>
i.e. to extend the building scheme that _already_ is applied for
building target-subpackages in case of cross-compilation (aka.
--target-subdir)
I am already applying a variant this configuration scheme in other
(non-gcc) packages.
> I proposed
> build-$build(_alias)-gcc.
Ralf
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-14 22:25 ` DJ Delorie
@ 2004-09-26 23:05 ` Marc Espie
2004-09-28 17:38 ` Per Bothner
0 siblings, 1 reply; 28+ messages in thread
From: Marc Espie @ 2004-09-26 23:05 UTC (permalink / raw)
To: dj; +Cc: gcc
I have trouble seeing gcc not building in src dir being a problem.
All the distributors I know don't have any issue with building stuff
with srcdir somewhere and objdir somewhere. Heck, most of them currently
insist on it anyways.
Does anyone have an instance of a current vendor build system that can't
cope with srcdir != objdir ?
Individual users can be very easily unconfused by the documentation.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Obsolete building in source dir?
2004-09-26 23:05 ` Marc Espie
@ 2004-09-28 17:38 ` Per Bothner
0 siblings, 0 replies; 28+ messages in thread
From: Per Bothner @ 2004-09-28 17:38 UTC (permalink / raw)
To: Marc Espie; +Cc: gcc
Marc Espie wrote:
> I have trouble seeing gcc not building in src dir being a problem.
gcc building is src dir is not important.
Having (./configure && make && make install) work is important, IMO,
since that is the "standard" way to build GNU (and lotsof other)
software.
--
--Per Bothner
per@bothner.com http://per.bothner.com/
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2004-09-28 16:47 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-11 4:06 Obsolete building in source dir? Giovanni Bajo
2004-09-13 7:34 ` DJ Delorie
2004-09-14 19:21 ` Joe Buck
2004-09-14 19:40 ` Zack Weinberg
2004-09-14 19:59 ` Joseph S. Myers
2004-09-14 20:12 ` DJ Delorie
2004-09-14 21:25 ` Zack Weinberg
2004-09-14 22:25 ` DJ Delorie
2004-09-26 23:05 ` Marc Espie
2004-09-28 17:38 ` Per Bothner
2004-09-15 11:09 ` Richard Earnshaw
2004-09-15 15:43 ` DJ Delorie
2004-09-15 16:16 ` Richard Earnshaw
2004-09-15 16:58 ` Phil Edwards
2004-09-15 21:15 ` Alexandre Oliva
2004-09-16 5:59 ` Ralf Corsepius
2004-09-16 16:47 ` DJ Delorie
2004-09-17 11:08 ` Ralf Corsepius
2004-09-17 21:12 ` DJ Delorie
2004-09-17 16:38 ` Alexandre Oliva
2004-09-18 15:14 ` Kai Henningsen
2004-09-18 17:31 ` Alexandre Oliva
2004-09-19 18:41 ` Kai Henningsen
2004-09-20 8:51 ` Ralf Corsepius
2004-09-16 22:01 ` Matthias B.
2004-09-14 20:08 ` DJ Delorie
2004-09-14 20:18 ` Joe Buck
[not found] ` <mailman.80195.1095191985.18468.gnu-gcc@lists.nsr.labs.mot.com>
2004-09-15 6:38 ` Loren James Rittle
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).