Subject: Re: Facing the GNU year

From: Dan Espen <[email-masked]>
Date: Tue, 06 Jan 1998 14:12:01 -0500

Steve Robbins <[email-masked]> writes:
> Hi,
> 
> I've polished off an autoconf'd version of 2.0.46 that -- I hope -- is
> decent enough to use in the next release.  It is now on my web page:
> http://www.cs.mcgill.ca/~stever/software/fvwm

I have tested this on Solaris 2.5 with Sun's compilers and "make".

> The major changes since the last time I announced here:
> 
> * the binary name is reverted to fvwm
> * config suffix reverted to .fvwmrc

I would like to retain  the binary name of  fvwm2  and the rc file  as
.fvwm2rc.  I didn't see how to do that.

> * modules in "extras" are configured and built, with the exception of
>   fvwmperl and fvwmpython
> 
> Comments, success or horror stories are most welcome.

1. I  don't know if this is  something that  can  be changed,  but the
naming on these options seems inconsistent:

	--with-lib-xpm=PATH
	--with-xpm-includes=DIR

2. I had a compilation failure with extras/FvwmCommand/FvwmCommandS.c.
It tried to include   "sunos_headers.h" which was  not  found.   Sun's
compiler apparently doesn't automatically define "SVR4".  I got around
this problem  by doing the configure  with  CFLAGS="-DSVR4".  (I don't
believe this has anything to do with the "configure" changes.

3. I had  an executable in my path  named "c++"  which wasn't working.
After I encountered the compilation error, I realized  I wanted to use
"CC" instead of "c++".   Maybe I'm ignorant, but I  had to look in the
"configure" script to find out that I  could override the C++ compiler
by setting   the   variable "CCC".  It   would be   nice  if  this was
documented somewhere.

4.  I'm pretty  sure this  is not under   our control, but I  find the
"configure.cache"   to  be a  pain.  After    I re-ran configure  with
"CCC=CC" on the command line, it still wanted to use "c++" because the
cache told it to use it.  I had to remove the cache  to get it to take
a fresh look  for the C++ compiler.  In  fact, I found that most times
when I   am re-running  configure, it  is  not  going to  see anything
different because of the cache.  My vote for  a default value for this
file would be "/dev/null".

5. Sun's C++ compiler didn't like a space between "-I" and the include
directory name.  It accepted the  "-I" by itself, and then  complained
that  it couldn't  do  anything  with  the  directory name.  I  should
mention  that I used --with-xpm-includes=DIR.   It  was this directory
that was preceded by a space.  Since the other "-I" args had no space,
I think  this should be  fixed, even though it  seems to be like Sun's
C++ compiler is lacking.

6.   The   file  "extras/FvwmConsole/FvwmConsole.c" wouldn't  compile.
Sun's compiler complained about the line:

char *xterm_a[] = {"-title", name,"-name",name, "-e",client,NULL };

Saying it  had a  "non-constant" initializer.   It was  the  automatic
variable   "client" that was  bothering  it.  I  realize this also has
nothing to do with configure.

7.  FvwmConsole  wouldn't link.   It needed  "-lsocket" on the command
line.  I'm not sure if "configure" was supposed to figure this out.

> --
> Steve Robbins                <[email-masked]>

--
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: lar3ry gensch <[email-masked]>
Date: Tue, 6 Jan 1998 15:00:58 -0500 (EST)

> .fvwm2rc.  I didn't see how to do that.

I don't like that feature either.  I've gotten used to typing 'fvwm2'
all over the place [smile].

I think that both "fvwm/.fvwmrc" and ".fvwm2/.fvwm2rc" could be
supported if Steve adds support for a new --with option on the
configure script.

	CC=cc ./configure --prefix=/usr/local --with-exename=fvwm
	CC=cc ./configure --prefix=/usr/local --with-exename=fvwm2

Comments anybody?

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."

---

From: Steve Robbins <[email-masked]>
Date: Thu, 8 Jan 1998 23:04:06 -0500 (EST)

> .fvwm2rc.  I didn't see how to do that.

You can't.  I could put back a configure option to do this.
 
> naming on these options seems inconsistent:

This can be partly changed.  The leading "--with-" is not changeable, but
the rest is.  What do you suggest?  Is this any more pleasing
aesthetically: 

	--with-xpm-lib[=PATH]
	--with-xpm-includes=DIR
 
> believe this has anything to do with the "configure" changes.

Thanks.  Not including sunos_headers.h in the distribution was an
oversight on my part.  But this file really should not be necessary.  I'd
like to get rid of it eventually.
 
> by setting   the   variable "CCC".  It   would be   nice  if  this was

OK
 
> file would be "/dev/null".

The rule of thumb is: if you change any "system characteristics", like the
compiler, or libc, or the like, you have to nuke the cache file before
running configure.  In other circumstances, the cache can speed things up
tremendously, to rerun configure with a different --prefix or --with-*
option, for example. 
 
> I think  this should be  fixed, even though it  seems to be like Sun's

Thanks; this is easily fixed.
 
> nothing to do with configure.

Argh.  I wish I had a compiler as picky as yours to find these things
with!  Maybe gcc has suitable warning flags that I can turn on.  I'll try
to fix this one for next time.
 
> line.  I'm not sure if "configure" was supposed to figure this out.

Are you sure it was FvwmConsole, and not FvwmConsoleC?  What function was
missing at link-time: connect?  Yes, configure should figure this out. 
And I'll fix it to do so soon. 

When love is gone, there's always justice.
And when justice is gone, there's always force.
And when force is gone, there's always Mom.

---

From: Dan Espen <[email-masked]>
Date: Fri, 09 Jan 1998 09:42:36 -0500

> You can't.  I could put back a configure option to do this.

I'm not convinced an option is  necessary, I would vote for hardcoding
this as fvwm2, but   I have a  strong suspicion   I  would be in   the
minority on this one.  I believe the default should be fvwm2.

> the rest is.  What do you suggest?  Is this any more pleasing

Looks good to  me, I was  mainly  bothered by  the order of  the words
changing.

> And I'll fix it to do so soon. 

Looks to me   like it would have happened   to  both FvwmConsole,  and
FvwmConsoleC.  I  only  saw  FvwmConsole, because after  I   fixed the
Makefile, both programs linked correctly.  Heres what I got:

cc -DSVR4  -o FvwmConsole  FvwmConsole.o -L../../libs -lfvwm  
Undefined			first referenced
 symbol  			    in file
socket                              FvwmConsole.o
accept                              FvwmConsole.o
send                                FvwmConsole.o
bind                                FvwmConsole.o
listen                              FvwmConsole.o

---

From: Kai Grossjohann <[email-masked]>
Date: 09 Jan 1998 16:45:00 +0100

>>>>> On Thu, 8 Jan 1998, Steve Robbins said:

  Steve> This can be partly changed.  The leading "--with-" is not
  Steve> changeable, but the rest is.  What do you suggest?  Is this
  Steve> any more pleasing aesthetically:

  Steve> 	--with-xpm-lib[=PATH]
  Steve> 	--with-xpm-includes=DIR

Do it like the --with-x-includes and --with-x-libraries switches.  I
think they use "libraries" instead of "lib", or was it "library"?  I
don't remember.  But the main thing is that it's logical to choose
option names that are consistent with the X option names, just to be
nice to the people running the configure script.

[time passes]

Oh, I see it's "--with-x-includes" and "--with-x-libraries" (at least
for Emacs), so you should choose "--with-xpm-includes" and
"--with-xpm-libraries".

kai
-- 
Kai Grossjohann, Informatik VI        [email-masked]
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
OOP: object oriented programming      OOPS: object oriented mistakes
--
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: "Charles Hines" <[email-masked]>
Date: Fri, 9 Jan 1998 10:46:46 -0500

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

>> You can't.  I could put back a configure option to do this.

Dan> I'm not convinced an option is necessary, I would vote for
Dan> hardcoding this as fvwm2, but I have a strong suspicion I would
Dan> be in the minority on this one.  I believe the default should be
Dan> fvwm2.

As do I...  I feel it helps eliminate confusion.

Often times people posting questions to the newsgroups and mailing
lists forget to mention what version they are working with, but at
least usually mention that it is 'fvwm2'.  It also helps keep people
from accidentally running fvwm2 with a 1.xx rc file and wondering why
it coredumped or produced really unexpected results.  Plus it allows
1.xx and 2.xx to both be installed on the same system easier and
safer.

Chuck

--
*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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: Steve Robbins <[email-masked]>
Date: Tue, 20 Jan 1998 00:22:21 -0500 (EST)

> nice to the people running the configure script.

This makes sense.  I changed the options to --with-foo-library, (since it
is typically ONE library and not a set of them, like for X) and
--with-foo-includes.

The current version also fixes all the compile problems mentioned in Dan
E's last email, and others sent to me privately.  

As the configure script per se settles down, I'm moving onto the second
phase of autoconf'ing the code.  Namely, going through the source and
replacing brittle constructs like:

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

with something like

	#if HAVE_SYS_SELECT_H
	...

where HAVE_SYS_SELECT_H is computed by configure, meaning the code is much
less likely to break in future (when some version of AIX stops shipping
sys/select.h) or work on new/mutant systems (which *have* sys/select.h,
but are not in the current list).

So if anyone knows of a good list of "portability pitfalls" to look out
for, I'd appreciate it!

I'd also like to clean up the code a bit, so that it will build without
warnings such as "gcc -Wall" gives:

	control reaches end of non-void function
	assignment discards `const' from pointer target type
	unused variable `i'

---

From: Steve Robbins <[email-masked]>
Date: Wed, 28 Jan 1998 22:38:40 -0500 (EST)

Hi all,

Due to overwhelming demand, I've put back in the option to name the binary
'fvwm2', with config file suffix '.fvwm2rc'.  This is the default, btw;
the switch exists to DISABLE putting '2' in the names.

I've also returned to NOT building the 'extra' modules by default (there
is an --enable-extras switch) simply because of problems with non-GNU
sunos and irix machines.

Beyond these config changes, I've started fixing the code so that it will
now compile with "gcc -Wall".  Currently, only "libs", "fvwm", and the two
modules I use compile cleanly using -Wall, on linux.  The priorities now
are to first have the main code compile cleanly using the IRIX and DEC
UNIX compilers, (which are pickier than gcc) and then work on modules.
I should probably learn to use 'lint' for this task...

I've had to start naming the versions I release.  I don't want to step on
toes, or to give people the impression that I've taken over maintenance of
fvwm (that's the last thing I need!).  Hence, I decided on the convention
of prefixing with my initials, and suffixing with a number.  This is
intended to indicate the NONOFFICIALNESS of the release. 

I'd rather have one of your minutes
than a year with all the hours in it.