Re: Again the build is broken :(

Re: Again the build is broken :(

[Kris Van Hees]

Well, 

1) If the time at which the automated builds run is significant in any way, we
   have a problem with our development procedures, because the quality of code
   (and the commits) should obviously not be time dependent.
   Also note that the builds are currently being executed at the following time
   slots:

	coldstone	3:34 am EST
	ca-tools2	4:45 am EST

   Given that the entire build-and-test cycle currently takes about 1 hour,
   that puts the completion of the latter right before EST dawn.

   And you can of course schedule your own builds using the automated build and
   test system at any time you want.  In fact, I'd highly recommend doing that,
   because it helps out everyone by increasing the overall build-and-test
   coverage.

2) I think you would definitely make a great contribution to the testing of
   frysk if you could create a per-commit test system.  I also believe it would
   make a nice complement to the current build-and-test system.  I look forward
   to hearing (and seeing) more about this.

   I'd like to point out though that there is nothing fuzzy about the point in
   time where a specific build was done by the automated build-and-test system.
   It is in fact possible (quite easily) to reconstruct the exact source tree
   that was used for the build (using CVS, so there is full access to commit
   log messages, etc...)

3) I don't think anyone has been reporting disaster in the event of build
   failures due to commits breaking the build, but I do believe that it is
   worth mentioning when it happens.  At a minimum, it raises the point that
   we are not as successful as we could be in making sure that commits are not
   breaking the builds.  Also, almost every single build failure *has* been
   discussed on IRC as soon as it was found (and resolution usually followed
   fairly shortly thereafter).  In this particular case, there was no IRC
   discussion (or at least, not initiated by me) simply because I was unable to
   connect to IRC at that given time.  Rather than not mentioning anything,
   sending mail to the list seemed quite reasonable under those circumstances.

	Cheers,
	Kris

> Elena Zannoni wrote:
>       
>> Sure, the two things you mention are not mutually exclusive.
>> However there is a cost to identifying broken builds too, and it seems 
>> that Mark is drawing the
>> short straw frequently, since he is usually the first to correct said 
>> oversights. It takes away some
>> of his time from development.
>>         
> Quite frequently, during the American day, we encounter and quick fix 
> similar issues (just today there was another "oops"), and we're 
> successfully and co-operatively managing these hiccups through our IRC 
> chatter and/or through bug reports and commits.
>
> However, we do need to be careful. Both Pearly and Mark pick up what I'll 
> call the night shift (from my tz pov) and so occasionally might be first 
> to encounter a problem also encountered by this build system. There I 
> think the most important thing is for us to be careful that we don't 
> message an expectation that Pearly and/or Mark are some how expected to 
> down-tools and focus all energies on getting it fixed.  As with us during 
> the day, back-date the check-out for a few hours 'til things are resolved; 
> for mark using mecurial, this is trivial.
>
> Can I suggest:
>
> - Moving the build farm's time to run just before US dawn so results are 
> better timed for us waking up; or better ...
>
> - setting up a test system that makes available results from individual 
> commits and not fuzzy dates
>
> - accept that an occasional build failure in the build farm does not 
> require an immediate post about the sky falling; I for instance would only 
> be concerned if the build failed consistently and for an identical reason 
> across two work days; and then my first response is still going to be to 
> fix it.
>
> Andrew
>
>
>       
>> I haven't suggested that you or anybody checks every combination
>> before checking stuff in. What I have suggested is that, like we used to 
>> do once upon a time, we
>> stick with as few development platforms as we can get away with in order 
>> to minimize the
>> oversights. So if the platforms supported are FC6 and F7, let's stick 
>> with those and make
>> everybody's life easier. If somebody wants to add FC5 to the test grid, 
>> please do so and contribute
>> the tests results so that they can be uploaded. Any takers?

Re: Again the build is broken :(

[Phil Muldoon]

Elena Zannoni wrote:
>>
>
> Sure, the two things you mention are not mutually exclusive.
> However there is a cost to identifying broken builds too, and it seems 
> that Mark is drawing the
> short straw frequently, since he is usually the first to correct said 
> oversights. It takes away some
> of his time from development. 

I'll segway into distributed version control here, my favorite pet topic 
;) It's great for isolating people from other peoples commits, and the 
ability to locally remove (or re-pull) whatever patch-sets you like. 
This a good thing, if a patch is bothering you then remove that 
change-set, then pull it later when it is mixed.

OTOH I think we all try to keep a stable CVS HEAD, but sometimes things 
just slip. Anyway, old ground there but ...
> What I have suggested is that, like we used to do once upon a time, we
> stick with as few development platforms as we can get away with in 
> order to minimize the
> oversights. So if the platforms supported are FC6 and F7, let's stick 
> with those and make
> everybody's life easier. If somebody wants to add FC5 to the test 
> grid, please do so and contribute
> the tests results so that they can be uploaded. Any takers?

I don't think the platforms have changed much since the time you talk 
about. But then again, there are other concerns now and in the future 
for other growth platforms. We have a Debian package now that Thomas 
works on. Mike is/was working on a Gentoo version. Fedora, RHEL and 
other distros. The math gets scary when you take platforms * 
architectures. Add into that the changing dynamics of the kernel across 
those platforms, and the only sane way to keep track of these is a build 
host.

Ideally, in a hardware rich world I'd like to submit a job to a build 
farm so it could lint all this automatically. Especially when I work on 
CNI code. I don't see the build farm failing as a "failure" but rather 
"doing its job".

Regards

Phil

Re: Again the build is broken :(

[Andrew Cagney]

Elena Zannoni wrote:
> Sure, the two things you mention are not mutually exclusive.
> However there is a cost to identifying broken builds too, and it seems 
> that Mark is drawing the
> short straw frequently, since he is usually the first to correct said 
> oversights. It takes away some
> of his time from development.
Quite frequently, during the American day, we encounter and quick fix 
similar issues (just today there was another "oops"), and we're 
successfully and co-operatively managing these hiccups through our IRC 
chatter and/or through bug reports and commits.

However, we do need to be careful. Both Pearly and Mark pick up what 
I'll call the night shift (from my tz pov) and so occasionally might be 
first to encounter a problem also encountered by this build system. 
There I think the most important thing is for us to be careful that we 
don't message an expectation that Pearly and/or Mark are some how 
expected to down-tools and focus all energies on getting it fixed.  As 
with us during the day, back-date the check-out for a few hours 'til 
things are resolved; for mark using mecurial, this is trivial.

Can I suggest:

- Moving the build farm's time to run just before US dawn so results are 
better timed for us waking up; or better ...

- setting up a test system that makes available results from individual 
commits and not fuzzy dates

- accept that an occasional build failure in the build farm does not 
require an immediate post about the sky falling; I for instance would 
only be concerned if the build failed consistently and for an identical 
reason across two work days; and then my first response is still going 
to be to fix it.

Andrew


> I haven't suggested that you or anybody checks every combination
> before checking stuff in. What I have suggested is that, like we used 
> to do once upon a time, we
> stick with as few development platforms as we can get away with in 
> order to minimize the
> oversights. So if the platforms supported are FC6 and F7, let's stick 
> with those and make
> everybody's life easier. If somebody wants to add FC5 to the test 
> grid, please do so and contribute
> the tests results so that they can be uploaded. Any takers?

Re: Again the build is broken :(

[Kris Van Hees]

On Fri, Aug 24, 2007 at 04:38:48PM +0200, Mark Wielaard wrote:
> I am personally using Fedora Core 6 (x86_64) as main development
> platform and test everything (quickly) on Fedora 7 (x86) before
> committing. But I guess other people have other platforms available. I
> do appreciate the autobuilder Kris setup since that shows some more
> platforms. Maybe we can change it a little to better show which patch
> breaks what on which platform, but that would mean actually building
> each commit, which might be a little too much for the system.

Actually, we could get fairly close to a per-commit building if we could get
the build process that frysk uses a bit more streamlined.  That might involve
quite a bit of work though, and someone will need to be given the cycles to do
it.  Even without a per-commit build it is possible to report on changes that
occured between two builds (and in fact, the web site currently provides all
anyone needs to do that already - the <blah>.rev files contain both a
date/time stamp of the checkout/update and a list of the exact CVS reivision
IDs, so comparing two you get an exact list of what files changed and what the
source and target revisions are per file).

Fortunately, it has almost always been extremely obvious what broke the build,
even wth just daily builds.  So, it may not be that big of a problem to solve
right now.

The ultimate problem remains though...  no one has made any contribution to
the autobuild system, and the one promise to contribute running builds never
happened.  There are limitations to how much can be done in reasonable time
without builds being contributed.

	Cheers,
	Kris

Re: Again the build is broken :(

[Elena Zannoni]

Phil Muldoon wrote:
> Mark Wielaard wrote:
>> Hi Elena,
>>
>> On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote:
>>  
>>> This leads to the question as to what are the standard development 
>>> platforms for frysk.
>>> FC6 and FC7? Or is older stuff still used? Should there be a 
>>> standard platform where
>>> pre-commit build and tests should be performed.
>>>     
>>
>> I am personally using Fedora Core 6 (x86_64) as main development
>> platform and test everything (quickly) on Fedora 7 (x86) before
>> committing. But I guess other people have other platforms available. I
>> do appreciate the autobuilder
> Personally I think an auto-builder is here for precisely the purpose 
> shown, in catching architecture-release build combinations breakages. 
> I just do not have the time to test arch * distro. The numbers add up, 
> and I normally test x86 and x86_64 on Fedora 7. There's no reason to 
> spend expensive and scarce human-time checking these, when a build 
> matrix can do it better, especially when the fixes are simple oversights.
> I'd rather have people contributing to features and fixing known bugs 
> and, to that end, making Frysk better.  And letting build matrices 
> build on every platform/release known to us, and linting test-cases 
> and build issues.
>

Sure, the two things you mention are not mutually exclusive.
However there is a cost to identifying broken builds too, and it seems 
that Mark is drawing the
short straw frequently, since he is usually the first to correct said 
oversights. It takes away some
of his time from development. I haven't suggested that you or anybody 
checks every combination
before checking stuff in. What I have suggested is that, like we used to 
do once upon a time, we
stick with as few development platforms as we can get away with in order 
to minimize the
oversights. So if the platforms supported are FC6 and F7, let's stick 
with those and make
everybody's life easier. If somebody wants to add FC5 to the test grid, 
please do so and contribute
the tests results so that they can be uploaded. Any takers?

elena

Re: Again the build is broken :(

[Phil Muldoon]

Mark Wielaard wrote:
> Hi Elena,
>
> On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote:
>   
>> This leads to the question as to what are the standard development 
>> platforms for frysk.
>> FC6 and FC7? Or is older stuff still used? Should there be a standard 
>> platform where
>> pre-commit build and tests should be performed.
>>     
>
> I am personally using Fedora Core 6 (x86_64) as main development
> platform and test everything (quickly) on Fedora 7 (x86) before
> committing. But I guess other people have other platforms available. I
> do appreciate the autobuilder
Personally I think an auto-builder is here for precisely the purpose 
shown, in catching architecture-release build combinations breakages. I 
just do not have the time to test arch * distro. The numbers add up, and 
I normally test x86 and x86_64 on Fedora 7. There's no reason to spend 
expensive and scarce human-time checking these, when a build matrix can 
do it better, especially when the fixes are simple oversights.

I'd rather have people contributing to features and fixing known bugs 
and, to that end, making Frysk better.  And letting build matrices build 
on every platform/release known to us, and linting test-cases and build 
issues.

Regards

Phil

Re: Again the build is broken :(

[Mark Wielaard]

Hi Elena,

On Fri, 2007-08-24 at 10:26 -0400, Elena Zannoni wrote:
> This leads to the question as to what are the standard development 
> platforms for frysk.
> FC6 and FC7? Or is older stuff still used? Should there be a standard 
> platform where
> pre-commit build and tests should be performed.

I am personally using Fedora Core 6 (x86_64) as main development
platform and test everything (quickly) on Fedora 7 (x86) before
committing. But I guess other people have other platforms available. I
do appreciate the autobuilder Kris setup since that shows some more
platforms. Maybe we can change it a little to better show which patch
breaks what on which platform, but that would mean actually building
each commit, which might be a little too much for the system.

Cheers,

Mark

Re: Again the build is broken :(

[Elena Zannoni]

Andrew Cagney wrote:
>
>> Got more info on the build? Architecture, distro, gcc, automake/autoconf
>> versions, etc?
>
> Seems its only triggered by newer autotools.
>
> Andrew
>

This leads to the question as to what are the standard development 
platforms for frysk.
FC6 and FC7? Or is older stuff still used? Should there be a standard 
platform where
pre-commit build and tests should be performed.

Re: Again the build is broken :(

[Andrew Cagney]

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

Seems its only triggered by newer autotools.

Andrew

Re: Again the build is broken :(

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

Hi,

On Fri, 2007-08-24 at 13:12 +0200, Mark Wielaard wrote:
> 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/autogen.sh: line 57: ../frysk/configure: No such file or directory
> 
> The reason I didn't see it before was that I wasn't doing a full clean
> build and there was still an old configure file left. Investigating.

OK, found it. automake thinks anything ending in _LDADD is "magic". So a
simple change to use a non-magic-sounding variable fixes things:

common/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.rules: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.
    * Makefile.gen.sh: Likewise.

frysk-core/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.

frysk-gtk/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.

frysk-gui/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.

frysk-imports/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.

frysk-sys/ChangeLog
2007-08-24  Mark Wielaard  <mwielaard@redhat.com>

    * Makefile.am: Change GEN_GCJ_LDADD to GEN_GCJ_LDADD_LIST.

Tested on FC6 with automake 1.9.6 and F7 with automake 1.10.
I don't know why this wasn't a problem before the removal of fryski
though. So some extra testing is appreciated.

Cheers,

Mark

[-- Attachment #2: ldadd_list.patch --]
[-- Type: text/x-patch, Size: 12880 bytes --]

Index: frysk-core/Makefile.am
===================================================================
RCS file: /cvs/frysk/frysk-core/Makefile.am,v
retrieving revision 1.116
diff -u -r1.116 Makefile.am
--- frysk-core/Makefile.am	16 Aug 2007 19:22:33 -0000	1.116
+++ frysk-core/Makefile.am	24 Aug 2007 11:29:25 -0000
@@ -51,26 +51,26 @@
 GEN_CLASSPATH += ../frysk-imports/getopt.jar
 GEN_CLASSPATH += ../frysk-imports/jdom.jar
 GEN_CLASSPATH += ../frysk-imports/cdtparser.jar 
-GEN_GCJ_LDADD += ../frysk-sys/libfrysk-sys.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jline.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-antlr.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-junit.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-getopt.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jdom.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-cdtparser.a 
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdwfl/libdwfl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdw/libdw.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a
+GEN_GCJ_LDADD_LIST += ../frysk-sys/libfrysk-sys.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jline.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-antlr.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-junit.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-getopt.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jdom.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-cdtparser.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdwfl/libdwfl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdw/libdw.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libebl/libebl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libelf/libelf.a
 if USE_LIBUNWIND
-GEN_GCJ_LDADD += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
                  ../frysk-imports/libunwind-x86_64/src/.libs/libunwind-x86_64.a \
                  ../frysk-imports/libunwind-ppc64/src/.libs/libunwind-ppc64.a
 endif
-GEN_GCJ_LDADD += -lstdc++
+GEN_GCJ_LDADD_LIST += -lstdc++
 # Stub bfd_getb32 and bfd_getl32 for PPC64.  Unconditionally
 # link -lbfd_get just for simplification.
-GEN_GCJ_LDADD += -laudit
+GEN_GCJ_LDADD_LIST += -laudit
 
 # For TestExec.java
 pkglib_PROGRAMS += frysk/pkglibdir/funit-exec-alias
Index: frysk-gtk/Makefile.am
===================================================================
RCS file: /cvs/frysk/frysk-gtk/Makefile.am,v
retrieving revision 1.38
diff -u -r1.38 Makefile.am
--- frysk-gtk/Makefile.am	16 Aug 2007 19:22:34 -0000	1.38
+++ frysk-gtk/Makefile.am	24 Aug 2007 11:29:25 -0000
@@ -48,22 +48,22 @@
 GEN_CLASSPATH += ../frysk-imports/getopt.jar
 GEN_CLASSPATH += $(FRYSK_GTK_JARS)
 
-GEN_GCJ_LDADD += ../frysk-sys/libfrysk-sys.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-junit.a 
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-getopt.a
-GEN_GCJ_LDADD += $(FRYSK_GTK_LIBS)
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdwfl/libdwfl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdw/libdw.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a
+GEN_GCJ_LDADD_LIST += ../frysk-sys/libfrysk-sys.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-junit.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-getopt.a
+GEN_GCJ_LDADD_LIST += $(FRYSK_GTK_LIBS)
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdwfl/libdwfl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdw/libdw.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libebl/libebl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libelf/libelf.a
 if USE_LIBUNWIND
-GEN_GCJ_LDADD += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
                  ../frysk-imports/libunwind-x86_64/src/.libs/libunwind-x86_64.a \
                  ../frysk-imports/libunwind-ppc64/src/.libs/libunwind-ppc64.a
 endif
-GEN_GCJ_LDADD += -lstdc++
+GEN_GCJ_LDADD_LIST += -lstdc++
 # For auditing
-GEN_GCJ_LDADD += -laudit
+GEN_GCJ_LDADD_LIST += -laudit
 
 # Hack, need to compile this entire sub-tree with JNI.
 AM_GCJFLAGS += -fjni 
Index: frysk-gui/Makefile.am
===================================================================
RCS file: /cvs/frysk/frysk-gui/Makefile.am,v
retrieving revision 1.98
diff -u -r1.98 Makefile.am
--- frysk-gui/Makefile.am	16 Aug 2007 19:22:34 -0000	1.98
+++ frysk-gui/Makefile.am	24 Aug 2007 11:29:25 -0000
@@ -54,30 +54,30 @@
 GEN_CLASSPATH += $(FRYSK_GUI_JARS) 
 GEN_CLASSPATH += /usr/lib
 
-GEN_GCJ_LDADD += ../frysk-gtk/libfrysk-gtk.a
-GEN_GCJ_LDADD += ../frysk-core/libfrysk-core.a
-GEN_GCJ_LDADD += ../frysk-sys/libfrysk-sys.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-antlr.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jdom.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-cdtparser.a 
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-junit.a 
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-getopt.a 
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jline.a 
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdwfl/libdwfl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdw/libdw.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a
+GEN_GCJ_LDADD_LIST += ../frysk-gtk/libfrysk-gtk.a
+GEN_GCJ_LDADD_LIST += ../frysk-core/libfrysk-core.a
+GEN_GCJ_LDADD_LIST += ../frysk-sys/libfrysk-sys.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-antlr.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jdom.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-cdtparser.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-junit.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-getopt.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jline.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdwfl/libdwfl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdw/libdw.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libebl/libebl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libelf/libelf.a
 if USE_LIBUNWIND
-GEN_GCJ_LDADD += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
                  ../frysk-imports/libunwind-x86_64/src/.libs/libunwind-x86_64.a \
                  ../frysk-imports/libunwind-ppc64/src/.libs/libunwind-ppc64.a
 endif
-GEN_GCJ_LDADD += -lstdc++
-GEN_GCJ_LDADD += ../frysk-gtk/libfrysk-ftk.a
-GEN_GCJ_LDADD += -L../frysk-gtk/EggTrayIcon
-GEN_GCJ_LDADD += -L../frysk-gtk/tlwidgets
-GEN_GCJ_LDADD += $(FRYSK_GUI_LIBS)
-GEN_GCJ_LDADD += -laudit
+GEN_GCJ_LDADD_LIST += -lstdc++
+GEN_GCJ_LDADD_LIST += ../frysk-gtk/libfrysk-ftk.a
+GEN_GCJ_LDADD_LIST += -L../frysk-gtk/EggTrayIcon
+GEN_GCJ_LDADD_LIST += -L../frysk-gtk/tlwidgets
+GEN_GCJ_LDADD_LIST += $(FRYSK_GUI_LIBS)
+GEN_GCJ_LDADD_LIST += -laudit
 
 # Skip the JUnit tests (exit with status 77) when there is no display; bug #3012.
 #TESTS_ENVIRONMENT = ( test $$tst != TestRunner || test -n "$$DISPLAY" || exit 77 ) && 
Index: frysk-imports/Makefile.am
===================================================================
RCS file: /cvs/frysk/frysk-imports/Makefile.am,v
retrieving revision 1.92
diff -u -r1.92 Makefile.am
--- frysk-imports/Makefile.am	16 Aug 2007 19:22:34 -0000	1.92
+++ frysk-imports/Makefile.am	24 Aug 2007 11:29:25 -0000
@@ -71,18 +71,18 @@
 
 GEN_CLASSPATH += getopt.jar
 GEN_CLASSPATH += junit.jar
-GEN_GCJ_LDADD += libfrysk-getopt.a
-GEN_GCJ_LDADD += libfrysk-junit.a
-GEN_GCJ_LDADD += ./elfutils/libdwfl/libdwfl.a
-GEN_GCJ_LDADD += ./elfutils/libdw/libdw.a
-GEN_GCJ_LDADD += ./elfutils/libebl/libebl.a
-GEN_GCJ_LDADD += ./elfutils/libelf/libelf.a
-GEN_GCJ_LDADD += -lstdc++
-GEN_GCJ_LDADD += ./libunwind-i386/src/.libs/libunwind-x86.a
-GEN_GCJ_LDADD += ./libunwind-x86_64/src/.libs/libunwind-x86_64.a
-GEN_GCJ_LDADD += ./libunwind-ppc64/src/.libs/libunwind-ppc64.a
+GEN_GCJ_LDADD_LIST += libfrysk-getopt.a
+GEN_GCJ_LDADD_LIST += libfrysk-junit.a
+GEN_GCJ_LDADD_LIST += ./elfutils/libdwfl/libdwfl.a
+GEN_GCJ_LDADD_LIST += ./elfutils/libdw/libdw.a
+GEN_GCJ_LDADD_LIST += ./elfutils/libebl/libebl.a
+GEN_GCJ_LDADD_LIST += ./elfutils/libelf/libelf.a
+GEN_GCJ_LDADD_LIST += -lstdc++
+GEN_GCJ_LDADD_LIST += ./libunwind-i386/src/.libs/libunwind-x86.a
+GEN_GCJ_LDADD_LIST += ./libunwind-x86_64/src/.libs/libunwind-x86_64.a
+GEN_GCJ_LDADD_LIST += ./libunwind-ppc64/src/.libs/libunwind-ppc64.a
 # For auding of system calls.
-GEN_GCJ_LDADD += -laudit
+GEN_GCJ_LDADD_LIST += -laudit
 
 # Need to get this into the distribution
 noinst_HEADERS = \
Index: frysk-sys/Makefile.am
===================================================================
RCS file: /cvs/frysk/frysk-sys/Makefile.am,v
retrieving revision 1.35
diff -u -r1.35 Makefile.am
--- frysk-sys/Makefile.am	16 Aug 2007 19:22:34 -0000	1.35
+++ frysk-sys/Makefile.am	24 Aug 2007 11:29:25 -0000
@@ -49,19 +49,19 @@
 GEN_CLASSPATH += ../frysk-imports/getopt.jar
 GEN_CLASSPATH += ../frysk-imports/jdom.jar
 GEN_CLASSPATH += ../frysk-imports/cdtparser.jar 
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jline.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-antlr.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-junit.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-getopt.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-jdom.a
-GEN_GCJ_LDADD += ../frysk-imports/libfrysk-cdtparser.a 
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdwfl/libdwfl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libdw/libdw.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libebl/libebl.a
-GEN_GCJ_LDADD += ../frysk-imports/elfutils/libelf/libelf.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jline.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-antlr.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-junit.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-getopt.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-jdom.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libfrysk-cdtparser.a 
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdwfl/libdwfl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libdw/libdw.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libebl/libebl.a
+GEN_GCJ_LDADD_LIST += ../frysk-imports/elfutils/libelf/libelf.a
 if USE_LIBUNWIND
-GEN_GCJ_LDADD += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
+GEN_GCJ_LDADD_LIST += ../frysk-imports/libunwind-i386/src/.libs/libunwind-x86.a \
                  ../frysk-imports/libunwind-x86_64/src/.libs/libunwind-x86_64.a \
                  ../frysk-imports/libunwind-ppc64/src/.libs/libunwind-ppc64.a
 endif
-GEN_GCJ_LDADD += -lstdc++ -laudit
\ No newline at end of file
+GEN_GCJ_LDADD_LIST += -lstdc++ -laudit
Index: common/Makefile.gen.sh
===================================================================
RCS file: /cvs/frysk/frysk-common/Makefile.gen.sh,v
retrieving revision 1.157
diff -u -r1.157 Makefile.gen.sh
--- common/Makefile.gen.sh	19 Jul 2007 20:32:08 -0000	1.157
+++ common/Makefile.gen.sh	24 Aug 2007 11:29:25 -0000
@@ -408,7 +408,7 @@
 noinst_LIBRARIES += lib${GEN_DIRNAME}.a
 ${sources} =
 ${nodist_lib_sources} =
-GEN_GCJ_LDADD += lib${GEN_DIRNAME}.a
+GEN_GCJ_LDADD_LIST += lib${GEN_DIRNAME}.a
 
 # Compile the .a into a .so; Makefile.rules contains the rule and does
 # not use libtool.
@@ -444,7 +444,7 @@
 CLEANFILES += TestRunner.java
 ${nodist_lib_sources} += ${GEN_SOURCENAME}/JUnitTests.java
 BUILT_SOURCES += ${GEN_SOURCENAME}/JUnitTests.java
-TestRunner_LDADD = \${LIBJUNIT} \${GEN_GCJ_LDADD}
+TestRunner_LDADD = \${LIBJUNIT} \${GEN_GCJ_LDADD_LIST}
 TESTS += TestRunner
 noinst_PROGRAMS += TestRunner
 EOF
@@ -491,7 +491,7 @@
 	    echo "${name_}_SOURCES ="
 	    echo "${name_}_LINK = \$(GCJLINK) \$(${name_}_LDFLAGS)"
 	    echo_LDFLAGS ${name}
-	    echo "${name_}_LDADD = \$(GEN_GCJ_LDADD)"
+	    echo "${name_}_LDADD = \$(GEN_GCJ_LDADD_LIST)"
 	fi
     done || exit 1
 done
Index: common/Makefile.rules
===================================================================
RCS file: /cvs/frysk/frysk-common/Makefile.rules,v
retrieving revision 1.242
diff -u -r1.242 Makefile.rules
--- common/Makefile.rules	24 Aug 2007 01:38:15 -0000	1.242
+++ common/Makefile.rules	24 Aug 2007 11:29:25 -0000
@@ -96,9 +96,9 @@
 
 # The list of libraries for the GCJ programs is different to that of
 # the standalone .c programs.  Accumulate the GCJ list in
-# GEN_GCJ_LDADD.
+# GEN_GCJ_LDADD_LIST.
 
-GEN_GCJ_LDADD = 
+GEN_GCJ_LDADD_LIST =
 
 # Take the LDADD list and transform it into a dynamic shared library
 # list.  This can then, in turn be converted into an in-build-tree
@@ -107,7 +107,7 @@
 
 # Convert LDADD's .a into -L<dir> -llib
 GEN_GCJ_SO_FLAGS = \
-	$(foreach lib, $(GEN_GCJ_LDADD), \
+	$(foreach lib, $(GEN_GCJ_LDADD_LIST), \
 		$(if $(filter -L%,$(lib)), $(lib)) \
 		$(if $(filter -l%,$(lib)), $(lib)) \
 		$(if $(filter %.a,$(lib)), \

Re: Again the build is broken :(

[Mark Wielaard]

Hi Kris,

On Fri, 2007-08-24 at 10:16 +0200, Mark Wielaard wrote: 
> > 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).

Doh. I lied (a little). Now that I do a completely fresh build
(including cloning a fresh source repository) I did get the same
failure.

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/autogen.sh: line 57: ../frysk/configure: No such file or directory

The reason I didn't see it before was that I wasn't doing a full clean
build and there was still an old configure file left. Investigating.

Cheers,

Mark

Re: Again the build is broken :(

[Mark Wielaard]

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

Again the build is broken :(

[Kris Van Hees]

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

The cause seems to be the following commit:

        2007-08-23  Andrew Cagney  <cagney@redhat.com>

        * Makefile.rules (fryski, gij.sh): Delete targets.

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.

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?

	Cheers,
	Kris