RE: "already configured" for dejagnu after gmake distclean.

[Hugh Sasse Staff Elec Eng <hgs at dmu dot ac dot uk>]

On Thu, 25 Mar 2004, Dave Korn wrote:

>
> > -----Original Message-----
> > From: binutils-owner On Behalf Of Hugh Sasse Staff Elec Eng
> > Sent: 25 March 2004 14:30
>
> > I'm still getting errors with dejagnu, when building binutils (CVS)
> > from scratch.
> >
> > See:
> > http://www.eng.cse.dmu.ac.uk/~hgs/binutils-cvs-failure.txt
> >
> > for the full details...
> >
> > edited highlights of which are below.
>
>   You *still* aren't building it from scratch.  Your source tree is *still*
> full of generated files, as the "cvs update" output shows.  The reason that
        [helpful comments elided]
>   As we see, in your source tree you have lots of generated files that
> shouldn't be there, and they are presumably wreaking havoc with the
> generated files in your build tree:
>
>
>   Why don't you do what the error message advises, and "make distclean" in

I did actually do that before any attempts to build in a new
directory, because before I was building in the source tree.

        [various ways of deleting the unwanted files trimmed]

Thanks for those. I did the most drastic thing, and /bin/rm -rf src
and re-got it from the cvs.  This has helped considerably, the build
continues much longer before it fails.  I'm starting a new thread on
that because it is not related to dejagnu.
>
>   The underlying problem is that you've first configured in the source
> directory and then tried to reconfigure for a parallel object directory
> build, and it's gotten your source tree into an inconsistent state; you must
> have not distcleaned between the two configures, and now you have makefiles

I am absolutely positive that I did that distclean in between,
forseeing this problem if I didn't.  It is well over a week ago
though, and I don't have any evidence lying around to prove this.
If it would help the code base become even more stable I could
rewrite my script to delete the src directory, get a fresh one,
build in that, `gmake distclean` and build in a parallel dir, to
rigorously test this.  I expect the development team would not put a
high value on the test results, though, because it is considered a
rare case.  If it would help prove things, or act as a "unit test"
for configure and/or make distclean, I'd be happy to contribute that on
the basis that it may the time of peole trying to build binutils,
and the time of people (such as yourself) who are generous enough to
advise the likes of me in such matters.

> in the source tree where they shouldn't be.  GNU source code is designed to
> be built either in a parallel directory or in the source directory itself,
> but it's not designed to switch from one method to the other; when configure
> is running in your new parallel object directory for the first time, it
> doesn't know about the previous configuration because the config.status and
> other files have ended up in the source tree.  In theory, configure could be
> protected against this, detect when generated files were found in the source
> tree, and automatically do a distclean itself, but people don't often tend
> to switch from the one style of building to the other, so it hasn't been
> done.

I'd suggest that this is more common than might be thought, because
it is one of the often-suggested remedies to an unsuccessful build,
that the build should be done in a different directory.  This is
going from what I have seen on gcc, binutils lists, anyway.
>
>
>
>     cheers,
>       DaveK

        Thank you, again,
        Hugh