Subject: FVWM CVS: fvwm domivogt

From: CVS <[email-masked]>
Date: Tue, 5 Jan 1999 13:37:37 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	99/01/05 13:37:37

Modified files:
	.              : ChangeLog NEWS Y2K-Compliance configure 
	                 configure.in 
Added files:
	archive        : announcement-2.1.7 
	archive/automated_tests: test_options 
Removed files:
	archive        : announcement-2.1.6 

Log message:
What's now going on with the Makefile.in's? I thought that was
resolved!

added announcement for 2.1.7, removed announcement for 2.1.6

added automatic build test: archive/automated_tests/test_options

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: 05 Jan 1999 14:42:33 -0500

%% CVS <[email-masked]> writes:

  c> What's now going on with the Makefile.in's? I thought that was
  c> resolved!

What do you mean?  Works fine for me.  What problem are you having?  I
just rebuilt every Makefile.in (because I've been mucking with configure
stuff) but they all came out the same as before (CVS considers them
unmodified).

  c> added announcement for 2.1.7, removed announcement for 2.1.6

It's kind of annoying to have these old files disappearing and new ones
appearing with each release.

Can't we just name the file Announcement or something, and update it for
each version?  That is, after all, what a source control system is for:
tracking changes to a file :)

-- 
-------------------------------------------------------------------------------
 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.hpc.uh.edu/fvwm/>.
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: Tue, 5 Jan 1999 21:17:41 +0100

> stuff) but they all came out the same as before (CVS considers them

When I committed the announcement et.al. I got the list of Makefile.in's
in the CVS comment form again. I can't imagine why since I built the last
version with exactly the same tools.

> tracking changes to a file :)

Of course we can :) As always this has historical reasons. The only
positive thing is that you run in no danger of using an old announcement
when these have the version number in their name.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 05 Jan 1999 16:09:33 -0500

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

  dv> When I committed the announcement et.al. I got the list of
  dv> Makefile.in's in the CVS comment form again. I can't imagine why
  dv> since I built the last version with exactly the same tools.

Easily debugged: use cvs diff on one of them to find out what changed:

  $ cvs diff fvwm/Makefile.in

---

From: Jason L Tibbitts III <[email-masked]>
Date: 05 Jan 1999 17:32:05 -0600

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

DV> When I committed the announcement et.al. I got the list of
DV> Makefile.in's in the CVS comment form again. I can't imagine why since
DV> I built the last version with exactly the same tools.

Get used to it.  This happens whenever the mtime of a file changes without
its contents changing.  A quick mtime-based scan will show the file as
modified when you're editing the commit message and the file will be sent
down the line for diffing (thus taking time) but no changes will be
recorded.  And this will happen every time you commit (use cvs -t to see
this).

I would suggest that we just get rid of all of the Makefile.in files and
require developers to have autoconf.  That's certainly what other projects
do, and it seems to work well enough.

Ideally the CVS tree would have no automatically generated files in it.

 - J<

---

From: [email-masked] (Paul D. Smith)
Date: 05 Jan 1999 21:35:31 -0500

%% Jason L Tibbitts III <[email-masked]> writes:

  jlt> Get used to it.  This happens whenever the mtime of a file
  jlt> changes without its contents changing.  A quick mtime-based scan
  jlt> will show the file as modified when you're editing the commit
  jlt> message and the file will be sent down the line for diffing (thus
  jlt> taking time) but no changes will be recorded.  And this will
  jlt> happen every time you commit (use cvs -t to see this).

Odd, I don't see this.  However, I always do a "cvs update" right before
the commit to make sure that everything is kosher; maybe that does the
diff and marks the file as unmodified?

  jlt> I would suggest that we just get rid of all of the Makefile.in
  jlt> files and require developers to have autoconf.  That's certainly
  jlt> what other projects do, and it seems to work well enough.

This would be OK with me but of course I already have all the tools :)

---

From: Dan Espen <[email-masked]>
Date: Wed, 06 Jan 1999 09:52:23 -0500

> Ideally the CVS tree would have no automatically generated files in it.

Wouldn't this make it harder for casual testers to do CVS downloads?
Perhaps if Linux ships with autoconf and friends pre-installed, this
is less of a problem than I imagine...

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Jason L Tibbitts III <[email-masked]>
Date: 06 Jan 1999 09:34:33 -0600

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> Wouldn't this make it harder for casual testers to do CVS downloads?

Perhaps, but it's the way most other autoconf and CVS-using projects I know
of work, and they don't seem to have any problems because of it.  The way
we do it now has certainly caused enough headache for us.

Essentially, you have to install CVS anyway, so what's two additional (and
tiny) packages?

DE> Perhaps if Linux ships with autoconf and friends pre-installed, this is
DE> less of a problem than I imagine...

With modern Linux packaging it doesn't really matter if it's pre-installed
or not.

 - J<