Subject: The GNU configuring scheme

From: Steve Robbins <[email-masked]>
Date: Fri, 7 Nov 1997 18:01:30 -0500 (EST)

Hi again,

I've already announced the autoconf patches for fvwm here.  Subsequently,
I was completely underwhelmed by the response.  Maybe you were put off by
my disclaimer?

> It's rather rough, but it is enough to build & install fvwm on the systems
> I've tested: linux 2.0, irix 5, sunos 4, and dec OSF/1.  
> 
> HOWEVER: in each case, I had gcc & all the GNU stuff installed.  So it
> really needs to be tested on some non-GNU systems.

Since that time, I have tested it without GNU tools.  It configures fine
under sunos 4, dec OSF/1, and irix 5 *without* GNU tools.  Since the code
is ANSI, it won't build under sun's default compiler.  Most folks with
sunos 4 know this, and should already have gcc installed.  Similarly, irix
5's make is buggy (or doesn't support VPATH at any rate) so you can not
build it in a directory other than the source directory. 

I have updated the kit from time to time; the version on the web now is
decent enough to be integrated into the next beta release.  

The software is at:

	http://www.cs.mcgill.ca/~stever/software/fvwm

Please take a look & pass on any comments you might have.

--
Steve Robbins                              <[email-masked]>

Don't know what I want, but I know how to get it.

--
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: Dan Espen <[email-masked]>
Date: Mon, 10 Nov 1997 11:18:57 -0500

> I was completely underwhelmed by the response.  Maybe you were put off by

I wasn't put off by the disclaimer.

I  have to guess,  but my  guess  is most people  on  this list have a
working fvwm2 build environment.  Ie. xmkmf  is working for them.  The
change to "config" would benefit new users more than existing users.

--
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: Steve Robbins <[email-masked]>
Date: Thu, 13 Nov 1997 10:21:52 -0500 (EST)

> change to "config" would benefit new users more than existing users.

Yes, I think this is exceedingly likely.  :)  I wasn't offering the
patches as a service to the people on this list; I was hoping, rather,
that people here would check the patches under various configurations so
that any problems could be quickly corrected.  Then, with luck, autoconfig
would make it into the next fvwm release, helping out those who are *not*
on this list.  Maybe even helping those who are mailing the fvwm list
about build problems ;-) 

In a more serious vein, I thought a discussion on build issues would be
helpful.  For example, some of the choices I made are slightly different
from the old behaviour.

* libXpm and librplay are probed for, and used by default if found; you
have to explicitly disable them if present on the system, but not wanted;
the old behaviour was that you had to explicitly enable or disable them

* I kept the tradition of installing all the modules and config file into
.../lib/fvwm[2]; this is a bit at odds with modern standards: modules
belong in libexec, and the config file in /etc or something; are there
strong feelings about this?

* utils are not installed by default; is there any reason not to install
them?

* there used to be an option to install the stuff in the sample.fvwmrc
directory; since _not_ installing is the common case, I removed this; 
hence one has to install them by hand the first time

* is there a reason for separating modules into "modules" and "extras"?  I
didn't touch the extras, so they have to be built the old way, which may
be harder if Fvwm.tmpl is gone; is it worth the bother of autconfiguring
them?  (It's on my list of things to do)

* there are way too many compile-time options: are they really needed, or
can they be made run-time options?

Too cool to live -- too smart to die.

---

From: Dan Espen <[email-masked]>
Date: Mon, 24 Nov 1997 14:13:29 -0500

> on this list.  Maybe even helping those who are mailing the fvwm list

OK, you convinced me to give it a try.  I'm using Solaris 2.5 with the
Xpm library and  include file installed   in a non-standard  place and
Suns compiler.

> the old behaviour was that you had to explicitly enable or disable them

My non-standard  xpm   library location always   causes problems  with
"configure".  One way I've found to get around it is to do this:

--x-includes="/usr/openwin/include -I/usr/WI/include"

The first directory  is without the  "-I" and the second one  includes
the "-I".  Essentially this fools "configure".

This worked.

I then  looked into the "configure"  executables and found  that there
was a "--with-xpm-includes=", so I tried that and during make I got:

/opt/SUNWspro3.0/bin/cc -DHAVE_CONFIG_H -I. -I. -I.. \
  -I/usr/openwin/include  -g -c Picture.c
"Picture.c", line 33: cannot find include file: <X11/xpm.h>

I added the  backslash.  I think  the "--with-xpm-includes=" should be
documented and work.

What I would really like  is for "configure" to look  at all the "lib"
directories in my $LD_LIBRARY_PATH, replacing "lib" with "include" and
find my xpm include directory without me doing anything.

> strong feelings about this?

Yes.   I don't think  thats the tradition.   At  any rate, I've always
installed my modules in the same place I installed the binary.  I also
install the  man pages in a  completely different area  than where the
binaries go.   The documented "--prefix" didn't work  for  me.  I then
checked the executables again and found I could use:

--exec-prefix=/myplace/sun_os5
--mandir=/myotherplace/man
--libdir=/myplace/sun_os5

However that didn't work as I wanted it to because it went and created

/myplace/sun_os5/bin  (for the binaries)
and
/myplace/sun_os5/fvwm2 (for the modules)

> * utils are not installed by default; is there any reason not to install

Yes.  I don't use or want to install them.

> hence one has to install them by hand the first time

The  documentation refers the  user to this file.  I  just took a look
and it doesn't seem to say where  it is.  I  would be nice if the make
procedure updated the man pages with the full path name.  I think this
file should be installed, perhaps in the bin?

> them?  (It's on my list of things to do)

I  think   there are 2 reasons   for  a module  to  be  in  the extras
directory,  either its not   fully  debugged, or  the  install process
hasn't been fully worked out.

> can they be made run-time options?

I think you  are refering to  the options like "GRADIENT_BUTTONS".  In
my opinion they  are compile time options  because fvwm2  is trying to
stay   true to its  original design  goal  of being  a small efficient
window manager.

I personally compile in all the options, but I think it would be nice to
document the way to turn them off.

The compile option was "-g" by default.  I think it should be "-O"?

---

From: Steve Robbins <[email-masked]>
Date: Wed, 26 Nov 1997 19:29:12 -0500 (EST)

On Mon, 24 Nov 1997, Dan Espen wrote:

Hi Dan,\

Thanks for all the comments.  I've tried to answer your questions as best
I could...

> --x-includes="/usr/openwin/include -I/usr/WI/include"

I'm guessing this means: normal X includes in /usr/openwin, and those for
xpm are in /usr/WI/include ...

> was a "--with-xpm-includes=", so I tried that and during make I got:

Yes; you should be able to use --with-xpm-includes=/usr/WI/include, and
you do NOT have to give --x-includes directly; automake will find them.
 
> I added the  backslash.  I think  the "--with-xpm-includes=" should be

Documented, it should be.  However, I think it *does* work.

Furthermore, configure goes to a lot of trouble to detect <X11/xpm.h> at
*configure* time, and will not attempt to use XPM unless it can find BOTH
the header and the actual link library.  I don't understand how you got
this behaviour.  Did you do "make distclean"  or equivalent between
configure runs?  Try my --with-xpm-includes suggestion above on a clean
source tree, and see what happens. 
 
> find my xpm include directory without me doing anything.

Well, I tried arguing a similar idea to the folks on the automake/autoconf
mailing list, and got shot down.  In fact, their reasons were sound, so I
think you have to live with the way things are.  

> Yes.   

Yes to which?  Change to "modules in libexec, config in /etc"?

> I don't think  thats the tradition.   

How so?  That's how the distributed Imakefiles do things.  What defines
"tradition" if not the traditional Imakefiles?

> The documented "--prefix" didn't work  for  me.  I then

In what manner did it "not work"?  I use it all the time, and it most
assuredly *does* work.
 
> /myplace/sun_os5/bin  (for the binaries)

Yes, that's the correct behaviour.  Notice that it is exec *PREFIX*!  The
binaries go in ${exec_prefix}/bin.

> and /myplace/sun_os5/fvwm2 (for the modules) 

Again correct.  Fvwm, like many software packages that install multiple
files into lib, creates a subdirectory (${libdir}/${packagename}) to hold
them all.
 
> procedure updated the man pages with the full path name.

Yes, that's a good idea: the man pages can be generated to substitute the
full pathnames for everything that gets installed: config file, modules,
etc.

> I think this file should be installed, perhaps in the bin? 

It should definitely not be installed into bin: it is a configuration
file.  

My preference is to put it with all the other config files: in /etc or
${prefix}/etc.  The latest Filesystem Hierarchy Standard
(http://www.pathname.com/fhs/) suggests /etc/X11, which I also like. 
 
> hasn't been fully worked out.

OK, but suppose I can work out the configuration bugs.  Then configure
should at least set up the makefiles to allow them to optionally be built
(i.e. "cd extras/foo; make") and optionally installed.

> I think you  are refering to  the options like "GRADIENT_BUTTONS".  

Yes, exactly.

> In my opinion they are compile time options because fvwm2 is trying to
> stay true to its original design goal of being a small efficient window
> manager. 

Yes, I suppose.  I should compile with them all off some day and see if it
makes any difference.

> The compile option was "-g" by default.  I think it should be "-O"?

Configure attempts to detect whether the compiler accepts both "-g and -O" 
together; if so, CFLAGS is set to "-g -O", ("-g -O2" for gcc) and
otherwise just to "-g".  Apparently, configure feels that your compiler
does not accept them both together.  If this is a bug, a note of it should
be submitted to the autoconf maintainers.

The CFLAGS are set for debugging by default.  This is a GNU standard, and
I think its a good one.  If you don't need debugging info, you can set
CFLAGS=-O and *either* configure *or* compile time.

Don't play cards with the Devil.  He'll deal you an awful hand.