I think autoconf is a nice thing to work towards. I have used it is house
and it is invaluable once the effort has been put in to convert a large
application to use configure. Its' primary author, David J. MacKenzie,
worked for me while a student at the University of Maryland, so I would
gladly see his work in wider use. However every time you muck with the build
procedure you will interject bugs or problems that will take several release
cycles to clean up. Look at what has happened to FVWM the last many months.
Besides trying to clean up things for the release, the Imake configureation
has gone through a couple good sized changes. Each time things that were
fixed before were broke. This will happen with autoconf also. This has also
slowed down the releses of FVWM ( In my opinion ), as constant build bugs
that are reported with each beta tend to keep people from pulling the newest
release once they have something installed and mostly working. This needs
to get fixed.
Maybe if Chuck had a few "elves" that he could have grab and try his
releases on several platforms before he publicly announced a release we
could clean up clean up the obvious bugaboos before it was announced.
A number of other lists that I am on do this with good success and there
products look much cleaner as a result of this. Typical there is something
like an "fvwm-workers" list, where those commited to supporting the product
can quickly prepare things for release. I do like the open forum of the
fvwm list though, but think something is in order.
I will personally volunteer to test early releases. I have HPUX, Solaris,
SunOS, IRIX, NetBSD, DU (OSF/1), and Ultrix systems I can test both vendor
and X11R6 builds against. If we had a couple/few volunteers for the major
OS's and X11's, then one of us for each or most OS's and X11's could get
back to chuck in a sort about of time so as not to slow up his releases by
more then 1 or 2 days at the most. The result will be better quality control
for FVWM.
There are many nuances with buiding things under X11. There are a number of
changes from R4, to R5, to R6 and between vendors that make it hard to get
things right if you do not test them on a number of platforms. Autoconf
will have to deal with some of these same problems. When I started
contributing my changes to the fvwm configuration, I at first only tested my
changes on a couple OS's and under X11R6 only. A number of bugs were
reported then by people who had differnet configurations then I tested
under. Later I started testing under more platforms and using various xmkmf
and X11 versions, and the bugs dropped way down. One more iteration would
probably have stabilized this. The decisions was made to make the build more
Imake-ish at this time, and the changes broke a number of things. Now a
couple iterations later and we still have one or two cycles go before the
build process will be release ready. Lets not do this again right now, as
there are alot more important FVWM things to work on. The current setup will
work fine for most of us with a couple more turns of the crank.
Again, I would like to see further beta releases address changes to the FVWM
code itself, and see the configuration/build process stabilized until after
FVWM-2.1 is released.
(my 2 cents worth)
Randall
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri May 24 1996 - 17:44:43 BST