Re: srcdir == objdir build issues [SC take note]

Re: srcdir == objdir build issues [SC take note]

[Benjamin Kosnik]

> FWIW, I very much like this approach. 

Did anybody not like this approach? I was surprised this did not go in.

-benjamin

Re: srcdir == objdir build issues [SC take note]

[DJ Delorie]

> Did anybody not like this approach? I was surprised this did not go in.

I had misgivings about a setup where you tell the software to do one
thing, and it does something completely different.  It also added a
maintenance headache for the "synthetic" top-level Makefile, since
every target in the real Makefile would have to be replicated (and
maintained - for ever).  It's far easier to just tell the user to
build elsewhere.

Re: srcdir == objdir build issues [SC take note]

[Ian Lance Taylor]

DJ Delorie <dj@delorie.com> writes:

> > Did anybody not like this approach? I was surprised this did not go in.
> 
> I had misgivings about a setup where you tell the software to do one
> thing, and it does something completely different.  It also added a
> maintenance headache for the "synthetic" top-level Makefile, since
> every target in the real Makefile would have to be replicated (and
> maintained - for ever).  It's far easier to just tell the user to
> build elsewhere.

For what it's worth, I agree.

Personally, I think the only reasonable choices are:

1) Have ./configure work in the expected and normal fashion; that is,
   put .o files next to the .c files, and only create new
   subdirectories for unusual cases like multilib.  This obviously
   requires regular testing, which is simple, and a commitment to keep
   it working, which is harder but should be doable.

or

2) Have ./configure simply fail with an error message directing the
   user to acquire GNU make and build in a different directory.

I think that having ./configure do something else is an increase in
complexity for no clear benefit.  I believe the point of having
./configure work is to make gcc behave like most other programs.  That
is, I think the goal ``./configure must work'' is incomplete.  The
right goal is ``./configure must behave as expected.''  Either
implement that goal, or have it fail in an obvious and straightforward
fashion.

Ian

Re: srcdir == objdir build issues [SC take note]

[Alexandre Oliva]

On May  9, 2003, DJ Delorie <dj@delorie.com> wrote:

> It also added a maintenance headache for the "synthetic" top-level
> Makefile, since every target in the real Makefile would have to be
> replicated

Not every target, only the standard ones, such as all, install, clean,
possibly bootstrap.  Or we could just finish ./configure by printing a
message such as:

        since the build instructions suggest you should build in a
        directory separate from the source tree, we went ahead and
        created it for you.  To build, cd to that directory and then
        make bootstrap or make all will work.

This will break for people who automate it with ./configure; make;
make install, but GCC has had a non-standard build procedure forever
(we recommend make bootstrap, not make), and the error may actually be
a good opportunity for people to actually read the installation
instructions.  Especially if the message actually points people at
it.

Hmm...  But then, why not go ahead and just fail to configure anyway.
Yeah...  It makes sense as well.  Maybe even more sense...

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: srcdir == objdir build issues [SC take note]

[Phil Edwards]

On Fri, May 09, 2003 at 09:40:20PM -0400, DJ Delorie wrote:
> It also added a
> maintenance headache for the "synthetic" top-level Makefile, since
> every target in the real Makefile would have to be replicated (and
> maintained - for ever).

That was never the goal.  Go back and read the archives again.

The idea was to make the "standard" sequence of

    ./configure
    make                (which actually did "make bootstrap")
    make install

work.  Nothing else.  Anything else would only be performed by maintainers
or other experienced users, and they could be relied upon to know the
"correct" procedure.


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: srcdir == objdir build issues [SC take note]

[DJ Delorie]

> work.  Nothing else.  Anything else would only be performed by maintainers
> or other experienced users, and they could be relied upon to know the
> "correct" procedure.

Its the people who don't know the correct procedures that scare me the
most ;-)

Re: srcdir == objdir build issues [SC take note]

[Alexandre Oliva]

On May  9, 2003, Phil Edwards <phil@jaj.com> wrote:

> The approach that Mark et al proposed and that I implemented doesn't
> require constant tweaking, like the current situation.  It doesn't need
> to be constantly tested.

FWIW, I very much like this approach.  It sounds like the right way to
solve the problem, if we decide that we want to support ./configure,
and I think we should.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: srcdir == objdir build issues [SC take note]

[Neil Booth]

DJ Delorie wrote:-

> SC - here are the options...
> 
> [ ] /some/dir/src/configure  (not matching any of the below)
> 
> [ ] ../src/configure
> 
> [ ] ../configure
> 
> [ ] ./configure

FWIW I've been doing ../configure since I started.  It only failed
once.  I know that at least 3 other regular contributors use it too.
So I don't think that has any problems with general support.

Neil.

Re: srcdir == objdir build issues [SC take note]

[Phil Edwards]

On Fri, May 09, 2003 at 02:41:51PM -0400, DJ Delorie wrote:
> 
> Given how much trouble I've had keeping ./configure working, I think
> any new twists will end up with the same fate.  At this point, I'd
> accept your solution if I thought it would help, but I think it would
> end up the same as what we have now - unsupportable.

The difference is that the twists up to this point have been spread
everywhere.  All through the configury, all through the makefiles.

> The problem is getting the regular gcc developers to test setups other
> than the common one.  Either they're going to test them, or they
> aren't.  If they're going to test them, we can continue supporting
> ./configure the "natural" way.  If they're not going to test them,
> let's not fool ourselves into thinking we can support it.

The approach that Mark et al proposed and that I implemented doesn't
require constant tweaking, like the current situation.  It doesn't need
to be constantly tested.

To remind the audience, what we're talking about had some discussion here:

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

and some patching here (note this was before the top-level autoconfiscation):

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


I like the idea of making our configury simply require/assume separate
build dirs, but there's no need to reject an in-srcdir *interface* just
because maintaining a parallel in-srcdir *implementation* has been a PITA.

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: srcdir == objdir build issues [SC take note]

[DJ Delorie]

> There's no reason to make it gratuitously fail.  I implemented a
> patch that would solve both problems: configury only has to deal
> with out-srcdir builds, plus the users can do "./configure; make"
> with no surprises.

Given how much trouble I've had keeping ./configure working, I think
any new twists will end up with the same fate.  At this point, I'd
accept your solution if I thought it would help, but I think it would
end up the same as what we have now - unsupportable.

The problem is getting the regular gcc developers to test setups other
than the common one.  Either they're going to test them, or they
aren't.  If they're going to test them, we can continue supporting
./configure the "natural" way.  If they're not going to test them,
let's not fool ourselves into thinking we can support it.  If the
solution is to build in a separate directory, let's just tell the user
that, require it, and get rid of all the cruft that's been added to
support anything else.  Just getting rid of the cruft will help with
maintenance costs too.

At least then the supported setups will be well tested and maintained.

Re: srcdir == objdir build issues [SC take note]

[Phil Edwards]

On Fri, May 09, 2003 at 01:55:52PM -0400, DJ Delorie wrote:
> I keep noting that every other source
> package besides gcc is build with "./configure; make" and we'd only be
> surprising the users if we don't allow it.

Very true.

> So here's an idea.  Let's ask the Steering Committee what we should
> support.  Whatever we choose to not support, I'll modify configure to
> detect and just plain fail, so there will be no doubts about the
> situation any more.

There's no reason to make it gratuitously fail.  I implemented a patch
that would solve both problems:  configury only has to deal with out-srcdir
builds, plus the users can do "./configure; make" with no surprises.

You rejected it because it would confuse a user who wanted to debug a
problem but would be confused when objects weren't in the same place as
the sources.  Which means, a user who

 - was proficient enough with computers to be building a compiler from scratch
 - cared enough to investigate the causes of a failed build
 - knew about ".c" files turning into ".o" files

but

 - hadn't read the documentation where we point out separate objdir builds,
 - didn't know how to type "ls" and notice brand new subdirs named "build-*"

I disbelieve such a user exists.


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: srcdir == objdir build issues [SC take note]

[DJ Delorie]

> there seems to be a fair number of people who like to build gcc with a 
> straight ./configure && make && make install. Unfortunately, this 
> doesn't seem to work a fair bit of the time, as is seen by the 10-20 
> bug reports we have about it in GNATS. The documentation 
> (http://gcc.gnu.org/install/configure.html) claims it _should_ work but 
> is not tested much. So my question is do we in fact support this, and 
> is it something which will receive regular testing?

Few gcc developers seem to care about building in anything other than
some unrelated directory.  I keep noting that every other source
package besides gcc is build with "./configure; make" and we'd only be
surprising the users if we don't allow it.  I do a build-in-srcdir
build every night, but often other problems prevent it from working,
so it's hard to keep on top of.

So here's an idea.  Let's ask the Steering Committee what we should
support.  Whatever we choose to not support, I'll modify configure to
detect and just plain fail, so there will be no doubts about the
situation any more.

SC - here are the options...

[ ] /some/dir/src/configure  (not matching any of the below)

[ ] ../src/configure

[ ] ../configure

[ ] ./configure

For those options the SC votes to support, we should expect anyone
submitting build-related changes to actually test those
configurations, in a worst-case scenario (most likely, a canadian
cross to a multilib target).

I've added binutils and gdb to this list, since the obvious place to
add these tests would be in the toplevel build files, so we should get
their opinion too - if they want to support things gcc doesn't, we'll
put the tests in gcc's configure.