Subject: Re: The GNU configuring scheme

From: Dan Espen <[email-masked]>
Date: Mon, 01 Dec 1997 11:27:48 -0500

Steve Robbins <[email-masked]> writes:
> 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...
> 
> > Steve Robbins <[email-masked]> writes:
> > 
> > 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"
> 
> I'm guessing this means: normal X includes in /usr/openwin, and those for
> xpm are in /usr/WI/include ...

Right.

> > 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:
> 
> 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.
>  
> > /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.
> 
> 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. 

I tried  make distclean, followed by  configure,  followed by make.  I
get   the  same problem.   Nearest   I  can tell   the  problem is  in
"libs/Makefile.in" which contains:

INCLUDES = $(X_CFLAGS)

as contrasted with "fvwm/Makefile.in" which contains:

INCLUDES = -I$(top_srcdir)/libs $(X_CFLAGS) $(XPM_CFLAGS) \
	-DFVWMDIR=\"$(FVWMDIR)\" 

(The value for $(XPM_CFLAGS) never gets  into $(INCLUDES) and so never
makes it to the cc command line.)

> > 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.
> 
> 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.  

OK, but, I think they are missing  out on a  very common situation.  I
don't have "root" access, so I can't install  the xpm library anywhere
"configure" will find it.  The only  hint configure could possibly use
to find  the xpm stuff is to  find the "lib" using LD_LIBRARY_PATH and
then look for a parallel "include" directory.

Sounds to me  like  they have "sound"  reasons for  their software not
working.

> > > * 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?
> > 
> > Yes.   
> 
> Yes to which?  Change to "modules in libexec, config in /etc"?

Yes, to strong feelings about this.

> > 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?

I thought when you   said "tradition" you were   referring to the  way
fvwm2 has been traditionally installed.

I think there are 2 subjects here, where the modules  go and where the
config file goes.  As  long as I can control   where they go,  I don't
care what the defaults are.

I can't install anything  in /etc.  I don't  have write access  to any
part of it.     Besides /etc is   local  to my   workstation.  Putting
something in /etc would make it invisible to others.

I don't know what "libexec" is.

I need a way of installing new  releases so that  I don't affect users
currently using fvwm2.  I currently install fvwm2 and its modules in a
place like <prefix>/fvwm-2.0.46/sun_os5.  I put  a shell called  fvwm2
in <prefix>/bin to figure out which version to run.

I  can't approximate this with  "configure"  unless I  set "prefix" to
something    that  includes the   fvwm2  release   number  and machine
architecture.

Even though I don't install fvwm2 so that the modules  are in my PATH,
somewhere in  the documentation, there  is an indication that  you can
tell what version of a  module you are running  buy  trying to run  it
from  the  command  line.   I think   modules should  default to being
installed in "--bindir".

> > The documented "--prefix" didn't work  for  me.  I then
> > checked the executables again and found I could use:
> 
> In what manner did it "not work"?  I use it all the time, and it most
> assuredly *does* work.

Well,  I meant it doesn't  work for me.  I  agree it  does work if you
accept what it does.  I really can't  replace fvwm2 while I have users
running it.   I therefore need to  install new releases in an isolated
area.  I use a shell called fvwm2 to figure out which release of fvwm2
to run.  Only the shell is in the users path.

> > --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)
> 
> Yes, that's the correct behaviour.  Notice that it is exec *PREFIX*!  The
> binaries go in ${exec_prefix}/bin.

Well, I can live with the extra "bin" at the end, but I would prefer a
way to do without it.

> > 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.

I guess  I can live  with this  also,  but the  modules aren't  really
libraries.  If they were  libraries, I would  want them in "lib" not a
directory below.  To provide the necessary release isolation I want, I
will have to set --libdir=<prefix>/fvwm-2.0.46/sun_os5.

> > > * 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
> > 
> > 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.
> 
> 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? 

I only picked "bin" because thats where I had it in the past.  As long
as its installed somewhere, its OK.

> 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. 

I read thru parts of this standard.  Thanks for the insight.

The document identifies /etc as host  specific, I don't think we don't
want to put anything concerning fvwm2 there.

I think this document suggests that fvwm2 belongs in /opt/fvwm2 with a
/opt/fvwm2/bin and an /opt/fvwm2/man.  I  have to disagree.  Even if I
could write    in that directory,   if I  did this  with  everything I
installed,  I would have  massive PATH and  MANPATH variables, plus no
release isolation.  Of course, I could create links to a common place,
and use /opt/fvwm-2.0.46,   but   the document doesn't   provide   any
guidance on where the links should be put.

I don't think this document adequately addresses software sharing on a
non-root basis.

> > > * 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)
> > 
> > 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.
> 
> 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.
> 
> > > * there are way too many compile-time options: are they really needed, or
> > > can they be made run-time options?
> > 
> > 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.
> 
> > 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"?
> 
> 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.

I'm  using Sun's compiler.  It  accepts "-g -O",  but not "-g -O2".  I
don't see  the logic in  "configure"  that would  accept "-g  -O"  for
anything but gcc.   I have to guess  that its a  bug.  When I  work on
fvwm2, I use "-g"  but I want the installed  copy to be "-O".  As long
as the override method is documented, I don't see a problem.

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

So far, I'm a  little concerned that the  "configure" approach  is not
quite  as robust as  the  "Imake" approach.  I'm  loosing the complete
control I used to have on where things are installed.  (The extra /bin
and /lib.)

So   far there is no      documentation how to   control things   like
"GRADIENT_BUTTONS".    I would guess  that  this  will involve editing
config.h?

--
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: Kai Grossjohann <[email-masked]>
Date: 02 Dec 1997 09:00:28 +0100

>>>>> On Mon, 01 Dec 1997, Dan Espen said:

  Dan> [about --prefix not working]
  Dan> Well,  I meant it doesn't  work for me.  I  agree it  does work if you
  Dan> accept what it does.  I really can't  replace fvwm2 while I have users
  Dan> running it.   I therefore need to  install new releases in an isolated
  Dan> area.  I use a shell called fvwm2 to figure out which release of fvwm2
  Dan> to run.  Only the shell is in the users path.

  Dan> [about --exec-prefix]
  Dan> Well, I can live with the extra "bin" at the end, but I would prefer a
  Dan> way to do without it.

Well, if --prefix and --exec-prefix were to behave differently than
they do, this would mean that the configure scheme for fvwm would
behave differently than the configure scheme for any other program.
Surely, users would be very surprised in the future if they expected
the fvwm configure script to behave like any other GNU configure
script.

I think that to do what you want the exact directory layout does not
matter.  All that matters is that you get some directory layout that
works for the things you're trying to do.  I do agree with you that it
would mean some effort to switch over from the old layout to the new
one, but I think one person's problems in that area shouldn't have
influence on the general behavior of the GNU configure script for
fvwm.

I haven't installed fvwm with configure, yet.  But I have installed a
number of other programs with GNU configure.  I choose

    ./configure --prefix=/foo/VERSION --exec-prefix=/foo/VERSION/ARCH

and this works fine for me.  Another possibility would be

    ./configure --prefix=/foo/ARCH/VERSION

In both cases, you can have some script in some other bin directory
with DTRT.

kai
-- 
`A wizard.  A ----ing wizard.  I *hate* ----ing wizards!'  `Well,
don't ---- him, then,' one of his henchmen said, effortlessly
pronouncing a row of dashes.  (Terry Pratchett)
--
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: Tue, 02 Dec 1997 09:09:18 -0500

> In both cases, you can have some script in some other bin directory

Hmm, DTRT, have to admit, I had to look it up.

OK, I'm convinced.   I concede that consistency  in operation  is more
desirable   than  me being able   to  reproduce  my  current directory
structure.

---

From: Steve Robbins <[email-masked]>
Date: Mon, 8 Dec 1997 02:05:43 -0500 (EST)

The following is rather long.  To summarise: a new version of
autoconfigured fvwm will appear on my web site tonight with the following
bug fixes:

* FVWMDIR is now ${libexecdir}/fvwm2
* CFLAGS fixed in libs subdirectory, so Xpm includes will be found
* all the configuration options are documented

Some questions posed in the message below:

* Should the modules actually be in a directory with the full FVWM
version attached; i.e. ${libexecdir}/fvwm-2.0.46?

* Should the runtime config file (system.fvwmrc) be located in
${sysconfdir}; i.e. ${prefix}/etc?

* Should any attempt at autoconfiguring the extras be made, or should they
be distributed separately.  IMHO, if they are not maintained by the fvwm2
author, it makes some sense to leave them out of the main package.
Particularly if no attempt is made to have them compile and work with each
release.

> > > I added the  backslash.  I think  the "--with-xpm-includes=" should be

[ ... ]

> makes it to the cc command line.)

Absolutely correct, thank you.  All my machines with Xpm have it in the
standard gcc paths, so I failed to find this. 

I have fixed this, and added a note (INSTALL.fvwm) on all fvwm-specific
configuration options.  In particular, --with-xpm-includes is now
documented. 
 
> "configure" will find it.  

Having a library installed somewhere that the compiler won't usually look
is indeed a *very* common situation, even for folks that have root.  That
is precisely the reason for the "--with-libxpm=PATH" and
"--with-xpm-includes=DIR" options. 

> The only hint configure could possibly use to find the xpm stuff is to
> find the "lib" using LD_LIBRARY_PATH and then look for a parallel
> "include" directory. 

This is not a general solution.  

First of all, there is no reason to assume the installer has
LD_LIBRARY_PATH set when compiling.  Indeed, I think this it is an
exceedingly bad idea to do so (sunos, for one, demands that
LD_LIBRARY_PATH be set at runtime also, which is a royal pain when moving
binaries around).  Also, XPM may be a static rather than shared library,
and hence may not appear in LD_LIBRARY_PATH.  Finally, even if libxpm.so
*does* appear there, there is no reason to assume that the include file
lives in a directory with lib->include. 

> config file goes. 

Correct.  Modules are now installed into ${libexec}/fvwm2.  For the
moment, the config file must also go there.  It is a small change to the
source code of fvwm/read.c to look for the config file elsewhere.  If
there is consensus (i.e. no dissent on the list) I will make that change
shortly.

> As long as I can control where they go, I don't care what the defaults
> are. 
>

OK, let's consider for the moment the case of the admin installing FVWM
systemwide.  I'll deal with non-root installs at the end.
 
> I don't know what "libexec" is.

`libexecdir'
     The directory for installing executable programs to be run by other
     programs rather than by users.  This directory name is derived
     at compile time as ${prefix}/libexec.  It will normally be
     `/usr/local/libexec'.

> something    that  includes the   fvwm2  release   number  and machine

Let's leave aside the multiple-architecture problem for a moment, and deal
with multiple versions of FVWM.  

The problem is then that the modules always get installed into the same
directory, namely ${libexecdir}/fvwm2.  One solution to this that I like,
is to use the full package+version string for the directory name.  So it
would be, for example, ${libexecdir}/fvwm-2.0.46.

> from  the  command  line.   I think   modules should  default to being

I disagree; ${bindir} is for programs that users normally run.  If I try
executing the modules, I just get things like:

	FvwmAudio Version 2.0.46 should only be executed by fvwm!
	FvwmAuto can use one to three arguments.
	Wanted argc == 6. Got 1
	FvwmTile: module should be executed by fvwm2 only

Since they are only to be executed by the program fvwm, clearly they
belong in ${libexecdir}.  If it is desired that users determine the
version number, they can be instructed to type the full pathname at the
command prompt: "/usr/local/libexec/fvwm-2.0.46/FvwmAuto".
 
> libraries.

They aren't libraries, but traditionally the meaning of "/usr/lib" (and
"/usr/local/lib") got overloaded.  The "libexec" dir was introduced
precisely to get these sort of non-library files out of "lib".

> If they were libraries, I would want them in "lib" not a directory
> below. 

It's a matter of taste.  For packages that install "several" files, (for
some definition of "several") into ${libdir} (or ${libexecdir}) it has
become customary for them to create their own subdirectory.  Since these
pathnames are typically compiled in, it is no great harm, usually. 

> want to put anything concerning fvwm2 there.

In fact, you *DO* want fvwm to look for it in /etc (or ${sysconfdir},
a.k.a. ${prefix}/etc, for autoconfigured packages).  This gives the
installer more flexibility.  If there is a config file good for multiple
machines, you can stuff it into a shared directory, and make a symlink
from /etc.  On the other hand, if one or more machines have a unique
setup, they can have their own config file in /etc.  The code in fvwm is
simple: just look in /etc, and assume the admin sorted things out. 

> /opt/fvwm2/bin and an /opt/fvwm2/man.

This is just one alternative.  It is not a good one, for reasons [omitted]
you pointed out.  The more common alternative is using
/usr/local/{bin,man,lib,libexec,etc}.  This is eactly what autoconfig
defaults to, and you can even specify another prefix, if you don't like
"/usr/local".  Perhaps some people do use "/opt" as the prefix. 

> I don't think this document adequately addresses software sharing on a

Right; it is intended for folks building OS releases.  Secondarily, it is
useful to people engineering packages (such as fvwm) as a guide to what
directories ought to be used.  

For present purposes, I pointed to it for a rationale for the autoconf
people's division of files into ${bindir}, ${libdir}, etc.  Once these
issues are understood, it is easy see how to deal with the non-root
install, by setting configure flags.

> > > document the way to turn them off.

Good idea; I cut & pasted the info out of the old configure.h file into
INSTALL.fvwm.

> as the override method is documented, I don't see a problem.

Hmm ... I don't see that it is explicitly documented.  The fact is,
however, you are able to override CFLAGS on the makefile command line, as
always: 

	make CFLAGS="..."
 
> control I used to have on where things are installed.  (The extra /bin

No, complete control is still there; see the output of "./configure
--help" for a complete list of options.  You can individually specify
${bindir} for the fvwm binary, ${libexecdir} for the modules, and
${sysconfdir} for the config file (although it is currently still in the
modules directory). 

For a typical sitewide install, one can specify just the --prefix, and
have everything else come out right.  Sites with multiple architectures
often use automounts, so that "/usr/local/bin" maps to the correct place
automatically.  These people can also just specify --prefix. 

For sites with multiple architectures, not using automounting, I suppose
they must use something icky like /usr/local/{architecture}/bin or
/usr/local/bin/{architecture} for binaries.  The former is easy to deal
with by specifying both --prefix and --exec-prefix, since both ${bindir}
and ${libexecdir} use the exec prefix.  For the latter style, you'd
probably have to specify --bindir and --libexecdir explicitly. 

For non-root installs where architecture is not a problem, you can simply
configure with --prefix=${HOME}, which installs into ~/bin and ~/libexec.
If multiple architectures pose a problem, you'd again need to resort to
specifying --bindir and --libexecdir separately.
 
> "GRADIENT_BUTTONS".    I would guess  that  this  will involve editing

The documentation is there now; and no, it doesn't involve any editing.
You ought not to even *have* a config.h file!

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

---

From: Jason L Tibbitts III <[email-masked]>
Date: 08 Dec 1997 01:55:34 -0600

>>>>> "SR" == Steve Robbins <[email-masked]> writes:

SR> * Should the modules actually be in a directory with the full FVWM
SR> version attached; i.e. ${libexecdir}/fvwm-2.0.46?

I see no reason why this would not be a good idea.  Version skew can easily
crop up, and when we get past 2.1 there will be many more sites which want
to make multiple versions available at the same time.

You might perhaps consider fvwm/2.0.46, though.  Many packages do this
(i.e. emacs, cf /usr/share/emacs/19.34).

SR> * Should the runtime config file (system.fvwmrc) be located in
SR> ${sysconfdir}; i.e. ${prefix}/etc?

I think so.  What are the alternatives?

SR> IMHO, if they are not maintained by the fvwm2 author, it makes some
SR> sense to leave them out of the main package.

Well, that's not necessarily a great assumption.  There's generally enough
warning before a release so that extras authors can get working versions of
their packages in before the release happens.  Plus given Chuck's free time
status, I expect that many things will end up not being maintained by him
but in the package anyway (as more folks contribute modules that Chuck
doesn't poke around in).

SR> The problem is then that the modules always get installed into the same
SR> directory, namely ${libexecdir}/fvwm2.  One solution to this that I
SR> like, is to use the full package+version string for the directory name.
SR> So it would be, for example, ${libexecdir}/fvwm-2.0.46.

Another solution is the one that Amanda (the backup suite) takes; it lets
you prepend version numbers to its subsidiary programs.  I like that much
less.  (And I rarely worry about 14 character filesystems.)

I used to think libexec was annoying, bur after working with packages that
have many subsidiary executables that aren't for human use I've grown to
rely on it.

[don't know who wrote this one; its lost in the quoting]
>> > > The compile option was "-g" by default.  I think it should be "-O"?

Not as long as the release is labeled beta.  Although I must admit I've
never understood the reason why it's called beta; it seems to be as stable
as anything else that's being released.

>> control I used to have on where things are installed.  (The extra /bin

Robustness and control are two very different things.  After dealing
endlessly with broken vendor imake config files, autoconf (for all its
complexity) is much easier to handle.

SR> You ought not to even *have* a config.h file!

I do think this is a worthy goal.  IMHO, the whole autoconf operation is an
incredibly good idea.  I'm not certain that I'd advocate it for 2.1,
though, but then it should depend on when 2.1 will be.  It does have one
large advantage in that Chuck doesn't have to maintain it (assuming Steve
wants to continue to do so) so that's one less thing he has to worry
about.  I'm all for making things easier for Chuck.

 - J<

---

From: Steve Robbins <[email-masked]>
Date: Tue, 9 Dec 1997 13:08:30 -0500 (EST)

> (i.e. emacs, cf /usr/share/emacs/19.34).

Ah, yes, that's good too; better, in fact, when multiple versions get
installed concurrently.  So the current suggestion is to install modules
into:
	${libexec}/fvwm/${version}

Might I suggest then, that the name of the binary be returned to simply
"fvwm", rather than "fvwm2"?  Those who install multiple versions can
rename it after install.  This would be more in keeping with current
practice: gcc and emacs, to name two, retain the same name for the
user-visible binary, even though they (well, emacs at least) have gone
through incompatible changes in the past.

> I think so.  What are the alternatives?

One alternative is to leave it in the module directory as it is now.  (I
don't really like that alternative)  There may be others, but I can't
think of any that I like.
 
> but in the package anyway (as more folks contribute modules that Chuck

True.

What I was thinking about when I wrote that, was how to get these things
configured & built.  At the moment, there seems to be a mishmash of
different schemes for building the extras: some have Imakefiles, some
(okay, one) have Makefile.std, some with nothing at all.  There is a big
fat warning in the original install file saying these things have to be
built by hand.  That suggested to me that while the code itself may be
maintained enough to compile or whatnot, the configure process may suffer
from version skew. 

>From the point of view of autoconf there are several possible choices:

1. Do Nothing

This is the choice I've taken so far, as it's the least amount of work
for me ;-)  This means, however, that the extras that use Imake have been
broken completely.  People won't like this option ...

2. Treat as modules

The extras directory could be treated in exactly the same way as the
modules, with a set of makefiles generated by configure.  This means the
configure script has to probe for all the features used in all these
extras, which includes: C++, perl, and python.  If these were not found,
configure would fail and fvwm could not be built.  This is unacceptable,
of course.  At least one module that uses C++ is put in extras because of
precisely the same problem with Imake.

3. Distribute separately, with their own configure script

This is essentially what I was suggesting before;  it is easier on me, the
autoconfigure script writer: I can just deal with fvwm proper, and leave
the extra module writers to fend for themselves.  :-)  In some sense these
things *are* separate packages, each needing their own configure script to
detect, for example, where the perl interpreter lives on your system.

4. Treat as *optional* modules

The configure script could be written with a switch (--with-extras ?) to
turn on checking for C++, perl, python and the rest.  The makefiles for
the extra modules are built only if this switch is enabled at configure
time.  This is something like options #1 and #2 combined; it is
all-or-nothing: if you don't have perl AND c++ AND python, then you can't
build the extras.  This is just a little work, but doesn't strike me as
terribly useful. 

5. Distribute with fvwm, each with their own configure script

This is a not-so-drastic version of option #3.  With some work, a small
configure script for each extra can be built.  The installer could:

	cd extras/foo && ./configure && make && make install

for each extra module desired.

6. Conditionally configure each extra

This is the "bells and whistles" option, which I'm not quite sure is
doable.  The idea is that the top-level configure script would probe for,
say C++, perl, etc.  Then, each module or extra with all prerequisites
available has its corresponding Makefile emitted.  The standard "make" 
commands will build / install all modules or extras which are buildable on
the given system.  In essence, the distinction between modules & extras is
dissolved. 

                  -------------------------------

I've started on option #5, but it will take some work.  I threw out the
suggestion for #3 to test the waters.  If nobody is using the extras, I
have other things to spend my time on :)  But if they are deemed integral,
I will finish off the configure scripts as best I can.  Of course, if they
are deemed integral, then #6 is the best option, and I'll investigate it
further.  There are a few technicalities with that option that I have to
check into.

> [don't know who wrote this one; its lost in the quoting]

It was Dan E.

> as anything else that's being released.

I really think the CFLAGS is a decision best left to the site's installer. 
Hence, nothing in the makefiles produced by configure relies on CFLAGS
being set in a particular way.  (For example, there are no "-I" nor "-L" 
flags stuffed into CFLAGS by configure)  Autoconf defaults CFLAGS to "-g" 
or "-g -O", so for the sake of consistency with all other autoconf'ed
packages, I suggest we leave it at that.  

You can always override it at configure *OR* compile time.  So you can do
a configure & test build (with CFLAGS = -g) for debugging, then recompile
before install with CFLAGS = -O. 

Some sites like to optimize everything, and I can sympathise with that. 
But I've been in enough instances where something that was in use for
months suddenly core dumps at a critical time.  I would have given
anything to have debugging symbols in the binary, so that I could at least
run gdb on it to see where the dump is happening --- without having to
recompile & reinstall. 

> complexity) is much easier to handle.

Amen to that!

One little-known feature of configure scripts produced by autoconf, is
that you can have site-wide defaults for common configure options.  For
example, at home I roll my own setup, compiling stuff into /usr/bin.  To
avoid specifying --prefix=/usr all the time, I have a config.site file
with:
	test "$prefix" = NONE && prefix=/usr
	test "$localstatedir" = '${prefix}/var' && localstatedir=/var

You can use the same trick if you like to set CFLAGS to -O2 always, or to
pass -I and -L options for libraries in weird places.

Admittedly this is an obscure feature, requiring a bit of inside knowledge
of autoconfig.  The only place I've seen it documented is in the autoconf
documentation.

> about.  I'm all for making things easier for Chuck.

Well, me too.  However, once the sources --- and developers ;-) --- have
been converted, there's nothing further for me to maintain.  I hope.

I'd probably be famous now, if I wasn't such a good waitress.