Subject: Re: CVS 'up' again

From: Steve Robbins <[email-masked]>
Date: Sun, 1 Nov 1998 14:54:54 -0500 (EST)

On Fri, 30 Oct 1998, Dominik Vogt wrote:

> I hope Steve will incorporate autoconf there on saturday.

OK, autoconf is in.  I'm very interested to hear reports of success or
failure with the new configure system! 

I hacked extras/FvwmTaskBar until it compiled, but I don't guarantee it
works. I had to retrieve an old version of Goodies.c, and restore
GetPicture() to libs/Picture.c.  See the ChangeLog and "cvs diff -r
pre_beta_2_1" for details. 

Other than that, the changes to actual source files are minor.

Everything now builds, so I took the liberty of tagging it as a "beta" 
version using "cvs tag version-2_1_0".  This follows the convention that
fvwm x.y.z is not stable if "y" is odd. 

The tag convention is that fvwm version x.y.z is tagged as "version-x_y_z" 
in the repository, for all beta & stable versions.  The corresponding tar
file is named "fvwm-x.y.z.tar.gz".

I have uploaded fvwm-2.1.0.tar.gz into the incoming/fvwm directory of the
ftp server.  I assume it will be moved appropriately in a day or two.

Note that there is one important difference between the beta version as it
exists in the CVS repository, and the tar file.  The tar file can be used
by anyone, whereas the makefiles in the repository use some GNUisms.  I
believe you'll need GNU make and GCC to build the repository version. 
However, you do NOT need any of the auto* tools to build either version. 

If you want to retrieve and build the beta from the CVS tree, do:

	cvs -d :pserver:[email-masked]:/home/cvs/fvwm login
[password is 'guest']
	cvs -d :pserver:[email-masked]:/home/cvs/fvwm \
		checkout -P -r version-2_1_0 fvwm
	cd fvwm
	more INSTALL*
	./configure 
	make

If you find a bug and fix it, you can very easily generate diffs using
"cvs diff" from the top of the source tree.  

If you are going to commit changes to the repository, you have to
understand sticky tags.  By doing a "checkout -r some-tag", you make
"some-tag" (e.g. "version-2_1_0" in the above example) sticky in your copy
of the repository. This means that all subsequent operations are based on
the version corresponding to "some-tag".  This is exactly what we want for
diffs, but it won't work for commits.

[The reason I gave explicitly the tag in the above is because it retrieves
precisely the version 2.1.0.  The head of the tree will become an unstable
alpha version very soon.]

If you are going to do commits they must be done at the head of the
repository tree.  So, either 

	* don't use the "-r" flag in the checkout or update,
or
	* issue the "cvs update -A" command before committing.

The latter option will update you to the current head of the trunk,
forgetting all sticky tags.  Pay careful attention to messages about
merges and conflicts! 

If you make changes to the sources, please change the version string in
configure.in to 2.1.1 before committing. 

The autoconf support included is only the basic stuff.  We need to go
through the sources and weed out obnoxious preprocessor stuff like:

	#if defined ___AIX || defined _AIX || defined __QNX__ || 
	    defined ___AIXV3 || defined AIXV3 || defined _SEQUENT_
	#include <sys/select.h>
	#endif

It can be replaced with:

	#if HAVE_SYS_SELECT_H
	#include <sys/select.h>
	#endif

If it is not apparent why this is a win, see the "ifdefs considered
harmful" paper I mentioned previously.  No, scratch that; *EVERYONE*
should read the paper!

There are many of these kinds of changes to be done.  As time permits,
I'll be going through the code making these changes.  In a similar vein, I
would also like to clean up dud, crap, and duplicated code.  I'd like "gcc
-Wall" to compile with no diagnostics, for example. 

The changes I have in mind shouldn't interfere too badly with further
development work of Dominik & Dan.  So if there are no objections, I'll
feel free to do these commits in parallel with their work on the trunk.

--
Steve Robbins                              <[email-masked]>

If I had a rocket launcher, some son of a bitch would die.

--
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: Tomas Ogren <[email-masked]>
Date: Sun, 1 Nov 1998 23:29:41 +0100

> failure with the new configure system! 

I'd like a "--with-xyz-prefix" to go with the
"--with-xyz-{includes,library}" ...

checking iconpath... /usr/include/X11/bitmaps:/usr/include/X11/pixmaps
Shouldn't be dup IMO..

Also... It doesn't install any system.fvwm2rc with 'make install'

This is on a solaris2.6 box...

/Tomas
-- 
Tomas Ögren, [email-masked], http://www.ing.umu.se/~stric/
|- Student of Computer Science at the University of Umeå
`- Sysadmin at {ing,acc}.umu.se
--
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: Brad Giaccio <[email-masked]>
Date: Mon, 2 Nov 1998 08:40:49 -0500 (EST)

I just checked out 2.1 Monday morning and tried to build.
>From extras I tried to compile FvwmCommand and FvwmConsole both of the
mgave me errors about stuff being redefined in sunos_headers.h.  I'm
building on solaris 2.5.1 and 2.6  but when I comment them out it builds
fine.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Steve Robbins <[email-masked]>
Date: Mon, 2 Nov 1998 10:10:48 -0500 (EST)

> building on solaris 2.5.1 and 2.6  but when I comment them out it builds

Right; sunos_headers.h is an abomination that can be removed now that we
have autoconf support. 

Thanks for reminding me about them. 

I am an anarchist.  
I am the antichrist.