Re: Again the build is broken :(

[Mark Wielaard <mark@klomp.org>]

Hi Kris,

On Fri, 2007-08-24 at 01:50 -0400, Kris Van Hees wrote:
> Again, we have a broken build with the following error:
> 
> <<part truncated because it is not relevant>>
> Running autoconf ... for libunwind
> Running aclocal ... for frysk-imports
> Running autoconf ... for frysk-imports
> Running automake ... for frysk-imports
> configure.ac: installing `./install-sh'
> configure.ac: installing `./missing'
> tests/Makefile.am: installing `./compile'
> tests/Makefile.am: installing `./depcomp'
> common/frysk-common.ac:222: installing `./config.guess'
> common/frysk-common.ac:222: installing `./config.sub'
> common/Makefile.rules:101: variable `GEN_GCJ_LDADD' is defined but no program or
> common/Makefile.rules:101: library has `GEN_GCJ' as canonic name (possible typo)
> Makefile.am:40:   `common/Makefile.rules' included from here
> Problem in directory frysk-imports
> ../frysk_config/autogen.sh: line 57: ../frysk_config/configure: No such file or directory

Got more info on the build? Architecture, distro, gcc, automake/autoconf
versions, etc?

> I hope Mark or anyone else in a more convenient timezone may be able to commit
> a fix for this.  Still recovering a bit from my travel yesterday, I'm more
> likely to cause additional problems than to solve this one right now.

As it happens in this timezone everything works after a fresh checkout
and fresh build (Fedora Core 6/x86_64, gcc 4.1.2-13, automake 1.9.6,
autoconf 2.59 and Fedora 7/x86, gcc 4.1.2-12, automake 1.10, autoconf
2.61).

I personally suspect the autotools or having to completely throw away
your build dir (which is what I just do each morning).

> Finally, it seems like we're getting a lot more broken build cases
> lately than we've had in the past months.  I am not sure what is
> causing this, because it seems like there have not really been any
> procedural changes that would cause this regression in quality.  That
> leaves the question: what can we do about this?  Assuming pre-commit
> testing is being done appropriately (i.e. using a clean slate - no
> left over configure scipts etc generated in a previous build), a
> problem like this can only be the result of a problem in how we
> perform the pre-commit testing.  What can we do to improive upon it?

Personally I have found it helpful to make sure I have a separate patch
that I can discuss and post to the list before committing. Often, just
the fact that I need to generate the diff, apply it to a clean build
(possibly on another machine) and just explain what the patch does helps
find any silly small mistakes with it.

Cheers,

Mark