Subject: Snapshot build failure 19990325

From: Jason L Tibbitts III <[email-masked]>
Date: 25 Mar 1999 10:47:13 -0600

make[2]: Entering directory `/home/tibbs/fvwm/fvwm'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../libs  -I/usr/openwin/include    -g -O2 -c add_window.c
In file included from add_window.c:46:
screen.h:335: nondigits in number and not hexadecimal
make[2]: *** [add_window.o] Error 1

screen.h:
334:    Bool MouseFocusClickRaises : 1;
335:    Bool StipledTitles : 1a;
336:    Bool WindowShadeScrolls : 1;

 - J<
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Thu, 25 Mar 1999 16:53:10 +0000

> 335:    Bool StipledTitles : 1a;

Oops. Finger trouble in between make and commit.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 25 Mar 1999 11:02:50 -0600

>>>>> "TP" == Tim Phipps <[email-masked]> writes:

TP> Finger trouble in between make and commit.

OK, I'll do a rebuild.  BTW, my script ended up being the following:

#!/usr/local/bin/zsh
VERSION=snap-`/usr/local/bin/date +%Y%m%d`;
SNAPDIR=/home/ftp/pub/fvwm/devel/snapshots;
cd ~/fvwm
/usr/local/bin/cvs update -dPA                   && \
/usr/local/bin/automake --add-missing            && \
/usr/local/bin/autoreconf                        && \
./configure                                      && \
 /usr/local/bin/make PERL=/usr/local/bin/perl5   && \
/usr/local/bin/make dist VERSION=$VERSION        && \
mv fvwm-$VERSION.tar.gz $SNAPDIR                 && \
cp -p ChangeLog NEWS $SNAPDIR

The build takes what seems like an eternity on this ancient box (Dual 50MHz
Sparc 10).  If someone tells me I need to stick a make clean or a rm
config.cache in there I'll go batty.

If I get independent verification that these snapshots are coming out OK,
I'll fix up the web page.

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 26 Mar 1999 12:41:48 +0100

> I'll fix up the web page.

In my eyes it's not even necessary that the snapshot compiles.
I thought they are only a way to fetch the source code in its
present state. It will happen fairly often that the snapshots
won't compile.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Fri, 26 Mar 1999 11:52:18 +0000

> present state. It will happen fairly often that the snapshots

True, but I wouldn't mind an automated message getting posted if it does
fail.

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 26 Mar 1999 11:10:45 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> In my eyes it's not even necessary that the snapshot compiles.
  dv> I thought they are only a way to fetch the source code in its
  dv> present state. It will happen fairly often that the snapshots
  dv> won't compile.

Hopefully not!  A goal of committing code is always that you're sure it
at least compiles, even if it doesn't work :)

Anyway, I agree that in one way it doesn't matter it compiles.  But on
some level, it must compile: the source tree (I think) should be
buildable by people who don't have the complete developer's suite
(that's why we're doing make dist after all!) so it has to compile far
enough to allow the dist to be built.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 26 Mar 1999 17:43:14 +0100

> enough to allow the dist to be built.

In theory, yes. But what are your plans to ensure this? I believe
most of us are very careful before committing, but sometimes it
just happens. The last time I checked in some conflict markers
I was relying on CVS to complain about this as I've seen before,
but not this time (why?).

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 26 Mar 1999 11:59:45 -0500

>> at least compiles, even if it doesn't work :)

  dv> In theory, yes. But what are your plans to ensure this? I believe
  dv> most of us are very careful before committing, but sometimes it
  dv> just happens.

I'm not saying it will never happen, but you said it will "happen fairly
often", which IMO is something altogether different: almost like it's an
expected occurrance.  I think it should be rare enough that it's always
a source of some amount of embarrassment :)

  dv> The last time I checked in some conflict markers I was relying on
  dv> CVS to complain about this as I've seen before, but not this time
  dv> (why?).

CVS doesn't search your file for conflict markers (if it did, how would
you put some text that happened to match them in your file?)

What it _does_, I think, is check timestamps/filesizes/something.  If it
noted a conflict during the update and then you commit and it sees that
you haven't changed the file since the conflict, it complains.  Also
note that as long as you haven't changed the file, subsequent updates
still leave the file marked as "C" (conflict), but as soon as you do so
the status of the file reverts to "M" (modified) again, even if some or
all of the conflict markers are still there.

If you change the file, but don't remove all the markers, it won't care;
it just thinks those markers are part of the normal text of the file.

You shouldn't rely on this kind of thing for error detection: building
is the only surefire way to know.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 26 Mar 1999 11:12:23 -0600

>>>>> "DV" == Dominik Vogt <[email-masked]> writes:

DV> In my eyes it's not even necessary that the snapshot compiles.

Unfortunately it has been said that the 'make' step is required for the
dependency information to be correct.  Otherwise I'd just do 'make dist'
and leave it at that.

 - J<

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 26 Mar 1999 18:13:29 +0100

> a source of some amount of embarrassment :)

Perhaps my English is failing me again. With 'fairly often' I meant
that you know it will happen from time to time and you are not surprised
to see it, even if it happens three times in a row. Probably my fault
was to translate the German 'h"aufig' to 'often'. In German it can
mean either 'frequently' or denote a wide range of frequencies. This
phrase may convey what I wanted to say in a better way: 
'not very frequently but more often than rarely'.
I am willing to learn. How would you have expressed this?

> all of the conflict markers are still there.

Yes, that's exactly what I expected. What I don't expect is this.

1) check out the complete sources; some conflicts occur
2) commit your code without touching any sources or compiling;
   the commit works fine

> is the only surefire way to know.

Not really. We had that problem with dependencies already.

Anyway, there is not much you can do to prevent commits at
3 AM in the morning :) Perhaps we should install some kind
of test that checks your mental awareness when you ty to
commit something 8-)

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 26 Mar 1999 18:18:40 +0100

> dependency information to be correct.  Otherwise I'd just do 'make dist'

Hmm. But the dependencies are generated even if compiling fails.
Correct?

Bye

Dominik ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 26 Mar 1999 12:57:42 -0500

> I am willing to learn. How would you have expressed this?
 
Something like:
'every once and a while'

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 26 Mar 1999 13:02:50 -0500

dv> Hmm. But the dependencies are generated even if compiling fails.
  dv> Correct?

No; it's the compiler that generates the dependencies--this is why GCC
is required for development: it can generate both a .o and a .P file
containing dependency info at the same time.  If it weren't for that,
any old compiler would do.

Actually, Tom has plans for the next version(?) of automake to allow for
a variety of dependency generation schemes, so developers won't be tied
to GCC anymore (GNU make would still be required, of course).

Anyway... I suggest you (Jason) run the make with the -k option.  Then
it would continue to at least build all other the .o files, even if it
can't link something, which will give you the dependency info for all
files except the ones that don't compile.

That's probably good enough for a snapshot.

---

From: [email-masked] (Paul D. Smith)
Date: 26 Mar 1999 13:06:23 -0500

dv> This phrase may convey what I wanted to say in a better way: 'not
  dv> very frequently but more often than rarely'.  I am willing to
  dv> learn. How would you have expressed this?

Probably I'd use a term like "occasionally".

I was mostly just kidding though :).

  dv> Yes, that's exactly what I expected. What I don't expect is this.

  dv> 1) check out the complete sources; some conflicts occur
  dv> 2) commit your code without touching any sources or compiling;
  dv>    the commit works fine

Hm.  Well, maybe commit doesn't care at all ?

I can't say I've either (a) tried this or (b) know enough about CVS to
say one way or t'other.

I do know about the update switching from "C" to "M", though :)

  dv> Anyway, there is not much you can do to prevent commits at
  dv> 3 AM in the morning :) Perhaps we should install some kind
  dv> of test that checks your mental awareness when you ty to
  dv> commit something 8-)

"You want to commit?  OK, follow this bouncing dot with your finger...
Now type the alphabet backwards..."

:)

---

From: Tim Phipps <[email-masked]>
Date: Mon, 29 Mar 1999 09:57:22 +0100

> 'every once and a while'

That desn't make sense to me, I'm used to "every once in a while".

Ignore me I'm English,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Mon, 29 Mar 1999 08:20:57 -0500

> That desn't make sense to me, I'm used to "every once in a while".

I think "every once in a while" is correct here in the States too,
but the part of about making sense isn't applicable.  Since when
does English (or American) make sense?

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]