objdir == srcdir is completely unsupported

objdir == srcdir is completely unsupported

[Gerald Pfeifer]

...according to our documentation, at least since:

  2002-04-15  Loren J. Rittle  <ljrittle@acm.org>

        * doc/install.texi (Installing GCC: Configuration): Clarify
        the only supported ways to configure gcc.

  First, in general, GCC @strong{must} be built into a separate directory
  than the sources which does @strong{not} reside within the source tree.
  This is how almost all developers build GCC; building where @var{srcdir}
  == @var{objdir} is completely unsupported; building where @var{objdir}
  is a subdirectory of @var{srcdir} is completely unsupported.

I remember that I was a bit confused by this change and sent some message
to the list, but I failed to find further details apart from:

  http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00102.html ff

Well, given recent discussions here, concerning Phil's patch which was
later reverted, I'm still confused.

Is this way of building GCC supported, or is it not? (In the former case,
we probably should change the documentation.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: objdir == srcdir is completely unsupported

[Phil Edwards]

On Thu, Jun 27, 2002 at 09:03:36PM +0200, Gerald Pfeifer wrote:
> Well, given recent discussions here, concerning Phil's patch which was
> later reverted, I'm still confused.

Here is the history as I can recall it:

Loren proposed the documentation patch.  It was approved and committed to
mainline and branch.

I pointed out that many moons ago, there had been some suggestions for
turning in-srcdir builds into a separate objdir, and so I threw out a
suggested patch.

IIRC, Mark recommended to Loren that the doc patch be kept on the branch and
reverted on the trunk, and recommended to me that the issue be revisited
after the 3.1 release (which was coming up soon).  I used to have all
the email from the above, until I did my semiregular mailbox weeding,
so I can't point you to a place in the archives.

More recently, I proposed and Mark approved the srcdir translating patch.
DJ pointed out that he had in fact formally rejected that patch, instead of
simply not liking it.  The patch was reverted on both trunk and branch,
even though srcdir builds were broken in the 3.1 release.  DJ then
applied a patch to both trunk and branch which he said seems to fix it.
(As an aside, the fix seems opaque to me, but apparently it's some kind
of autoconf thing not happening in the right order, or something.)

Loren's doc patch remains on the branch.

This brings us to the present.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: objdir == srcdir is completely unsupported

[Loren James Rittle]

In article <20020627164520.A24749@disaster.basement.lan>,
Phil Edwards<phil@jaj.com> writes:

> On Thu, Jun 27, 2002 at 09:03:36PM +0200, Gerald Pfeifer wrote:
>> Well, given recent discussions here, concerning Phil's patch which was
>> later reverted, I'm still confused.

Hey guys,

I already filed some private commentary last week.  But it appears I
can't get out of being dragged into this issue again.  Let me plop my
diplomat hat on before starting.

> Here is the history as I can recall it:

> Loren proposed the documentation patch.  It was approved and committed to
> mainline and branch.

True.

> I pointed out that many moons ago, there had been some suggestions for
> turning in-srcdir builds into a separate objdir, and so I threw out a
> suggested patch.

True, and I referred to those past suggestions and lack of approved
and committed implementation and/or other general improvements to fix
the situation.

> IIRC, Mark recommended to Loren that the doc patch be kept on the branch and
> reverted on the trunk, and recommended to me that the issue be revisited
> after the 3.1 release (which was coming up soon).  I used to have all
> the email from the above, until I did my semiregular mailbox weeding,
> so I can't point you to a place in the archives.

Actually, the patch was reverted on the 3.1.X branch but not on the
mainline/trunk.  Unless I messed up following instructions, I am quite
certain that I was asked to do it that way...

Rationale from memory: The patch was reverted on 3.1.X branch since
enough patches went in right before the release to make enough people
think that in-source configuration was now working.  Unfortunately,
due to no one's fault, it appears that some/all multilib in-source
configurations actually shipped broken.  I know I don't test such an
in-source configuration.  Oh well, no matter how we slice it, that is
the price we pay for allowing our users to configure our source tree
as *zero* active gcc developers nominally do it... (and which was the
point of my whole argument for the documentation patch...)

(Let me readjust my diplomat hat, it just fell off for a moment. ;-)

Lest we forget, DJ spoke up that he was willing to fix such issues
with in-source configuration as they were reported and he has lived up
to his word to a tee.

> More recently, I proposed and Mark approved the srcdir translating patch.
> DJ pointed out that he had in fact formally rejected that patch, instead of
> simply not liking it.  The patch was reverted on both trunk and branch,
> even though srcdir builds were broken in the 3.1 release.  DJ then
> applied a patch to both trunk and branch which he said seems to fix it.
> (As an aside, the fix seems opaque to me, but apparently it's some kind
> of autoconf thing not happening in the right order, or something.)

We may not agree with how DJ fixed it but he lived up to his word to
do so.

> Loren's doc patch remains on the branch.

Correction: The doc patch in question remains on the mainline.

> This brings us to the present.

Yes, thank you for writing it all down before I started.  I am not
recommending any action; only adding/correcting the history.

Regards,
Loren

Re: objdir == srcdir is completely unsupported

[Phil Edwards]

On Thu, Jun 27, 2002 at 05:00:04PM -0500, Loren James Rittle wrote:
> > IIRC, Mark recommended to Loren that the doc patch be kept on the branch and
> > reverted on the trunk, and recommended to me that the issue be revisited
> > after the 3.1 release (which was coming up soon).  I used to have all
> > the email from the above, until I did my semiregular mailbox weeding,
> > so I can't point you to a place in the archives.
> 
> Actually, the patch was reverted on the 3.1.X branch but not on the
> mainline/trunk.  Unless I messed up following instructions, I am quite
> certain that I was asked to do it that way...

You're probably right.  This is what I get for weeding.


> Oh well, no matter how we slice it, that is
> the price we pay for allowing our users to configure our source tree
> as *zero* active gcc developers nominally do it... (and which was the
> point of my whole argument for the documentation patch...)
> 
> (Let me readjust my diplomat hat, it just fell off for a moment. ;-)

Maybe the regression testing scripts could do it?


> Lest we forget, DJ spoke up that he was willing to fix such issues
> with in-source configuration as they were reported and he has lived up
> to his word to a tee.

Absolutely.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: objdir == srcdir is completely unsupported

[Geoff Keating]

Phil Edwards <phil@jaj.com> writes:

> On Thu, Jun 27, 2002 at 05:00:04PM -0500, Loren James Rittle wrote:
> > Oh well, no matter how we slice it, that is
> > the price we pay for allowing our users to configure our source tree
> > as *zero* active gcc developers nominally do it... (and which was the
> > point of my whole argument for the documentation patch...)
> > 
> > (Let me readjust my diplomat hat, it just fell off for a moment. ;-)
> 
> Maybe the regression testing scripts could do it?

The regression testing scripts try to do things exactly as the typical
GCC developer does them.  The regression tester's primary purpose is
to keep the tree stable to allow more development, not to keep GCC
stable enough for a release (although that's an important secondary
purpose).

The best way to make configuring in the source tree work is to make it
harder to break it, whether by the use of automated tools (like
automake), better design (make configuring in the source tree make a
subdirectory and configure in that), or whatever.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: objdir == srcdir is completely unsupported

[DJ Delorie]

> Is this way of building GCC supported, or is it not? (In the former case,
> we probably should change the documentation.)

It is supported.  That doesn't always mean it *works*.  It means that
if there are bugs, I will address them.

The documentation, of course, should reflect reality rather than some
hopeful future, if we find we cannot fix particular bugs.

Re: objdir == srcdir is completely unsupported

[Gerald Pfeifer]

On Mon, 1 Jul 2002, DJ Delorie wrote:
>> Is this way of building GCC supported, or is it not? (In the former case,
>> we probably should change the documentation.)
> It is supported.  That doesn't always mean it *works*.  It means that
> if there are bugs, I will address them.
>
> The documentation, of course, should reflect reality rather than some
> hopeful future, if we find we cannot fix particular bugs.

Well, but currently the documentation quite strongly claims it is
"completely unsupported" [doc/install.texi] -- do you want to change that?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: objdir == srcdir is completely unsupported

[DJ Delorie]

> Well, but currently the documentation quite strongly claims it is
> "completely unsupported" [doc/install.texi] -- do you want to change
> that?

It would probably be correct to change it now.