Subject: FVWM: Gnu configure on next realease ???

From: Gallego Serge <[email-masked]>
Date: Wed, 22 May 1996 18:33:15 +0200 (MET DST)

Hi.

The fvwm 2.0.42 TO-DO says :

  "  - Switch from Imake to GNU autoconf?

What about that ?
Someone knows if this will be done ?

						Gallego Serge

--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: まつしたまこと <[email-masked]>
Date: Thu, 23 May 1996 03:49:36 +0900

gallego>   "  - Switch from Imake to GNU autoconf?
gallego> What about that ?

It says all :-)

I've already posted a patches to this list twice (for version 1.?? and
version 2.0.??, sorry I forgot), which make fvwm to configure the OS
specific section (ex. use sysconf or not) with GNU autoconf.

But, IMHO (comes from the experiences of making patches),

a) Most of all applications for X use imake and that's maybe the way
   of X. There is no reason that fvwm denies this manner.

b) Switching to GNU autoconf is not suitable. Though GNU autoconf is
   great, imake knows ALL about development environment for X
   application and GNU autoconf (maybe) don't, sometimes mistake
   (That's the reason that patch for 1.xx was not included to fvwm).

c) Using imake and configure (yes, my patches do so) is tired :-)
   (We should run both 'configure' and 'xmkmf' before 'make')

We should carefully consider the usage of GNU configure to fvwm.

- -
Makoto `MAR_kun' MATSUSHITA

---

From: <[email-masked]> (Charles Hines)
Date: Wed, 22 May 1996 16:36:13 -0400

>>>>> "matusita" == matusita  <ISO-2022-JP> writes:

matusita> It says all :-)

I agree.

BTW, the '?' at the end of those TO-DO list items generally indicates
"I don't know if this should or will actually be done or attempted,
but I plan to investigate when I get a chance" or some variation of
that theme.

matusita> I've already posted a patches to this list twice (for
matusita> version 1.?? and version 2.0.??, sorry I forgot), which make
matusita> fvwm to configure the OS specific section (ex. use sysconf
matusita> or not) with GNU autoconf.

I have both patches from Matsushita-san.  When I investigate, I'll use
those as starting points.

matusita> But, IMHO (comes from the experiences of making patches),

matusita> a) Most of all applications for X use imake and that's maybe
matusita>    the way of X. There is no reason that fvwm denies this
matusita>    manner.

True.  The main reason I wanted to try autoconf is for those systems
that have messed up Imake config files or don't have it installed at
all (default for AIX and HPUX it seems).

matusita> b) Switching to GNU autoconf is not suitable. Though GNU
matusita>    autoconf is great, imake knows ALL about development
matusita>    environment for X application and GNU autoconf (maybe)
matusita>    don't, sometimes mistake (That's the reason that patch
matusita>    for 1.xx was not included to fvwm).

matusita> c) Using imake and configure (yes, my patches do so) is
matusita>    tired :-) (We should run both 'configure' and 'xmkmf'
matusita>    before 'make')

matusita> We should carefully consider the usage of GNU configure to
matusita> fvwm.

I only intend to use it if it can seamlessly replace the Imake stuff
entirely.  When I investigate, I'll probably have some releases with
both methods of building in there, to flush out bugs and test all
system feasability.

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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Anthony Martin <[email-masked]>
Date: Wed, 22 May 1996 14:30:10 -0700 (PDT)

>    (That's the reason that patch for 1.xx was not included to fvwm).

Imake doesn't know all about the development environment.  It knows about
the development environment that the OS vendor thinks you should have.
After all, everyone buys a commercial compiler from the OS vendor rather
than using GCC, right? :-)

Autoconf uses Imake if it is available to find relevent information such
as locations of libraries and include files and the names of any special
libraries that might be needed, but it doesn't make any assumptions about
what compiler you have installed.   Autoconf checks for itself to find
your compiler and much other system-specific information.  I think this is
the better solution.

Tony.

---

From: まつしたまこと <[email-masked]>
Date: Thu, 23 May 1996 15:04:31 +0900

amartin> Imake doesn't know all about the development environment. 

If your imake doesn't know all about the development environment,
that's the misconfiguration of imake :-) Imake SHOULD know the environment.

amartin> After all, everyone buys a commercial compiler from the OS
amartin> vendor rather than using GCC, right? :-)

Hmm :-) Then, everyone gets X11R6 distribution and make their own X if
they can, right? :-)

amartin> Autoconf uses Imake if it is available to find relevent
amartin> information such as locations of libraries and include files
amartin> and the names of any special libraries that might be needed,

Sorry I'm not familiar with autoconf, Does autoconf uses the
informaiton of $XTOP/lib/config ? or simply kicks imake to use ?

***

Maybe the best (ie, easy, reliable, and portable) procedure of fvwm
compilation is:

1) Edit configulation file to specify the features (XPM and so on).
	It should be included to step 2) ?
2) do './configure'.
	Configure makes Imakefile, and do 'xmkmf', 'make Makefiles',
	and so on ('xmkmf -a' is enough ?).
3) do 'make'.
	**/Makefile is already generated by imake.
4) do 'make install'
	Wow, it's happy :-)

Any comments ?

- -

---

From: Anthony Martin <[email-masked]>
Date: Thu, 23 May 1996 00:40:24 -0700 (PDT)

> informaiton of $XTOP/lib/config ? or simply kicks imake to use ?

The configure script generated by autoconf creates a very simple Imakefile
and then it runs xmkmf and looks at the generated Makefile to get the
following variables (these are on my linux system, they will differ):

ac_im_incroot="/usr/X11R6/include";
ac_im_usrlibdir="/usr/X11R6/lib";
ac_im_libdir="/usr/X11R6/lib/X11"

Then it isn't so foolish to assume that these are the actual locations, it
checks to make sure.  If these aren't the correct locations, then it
continues to look in a bunch of common places to find the real libraries
and includes.

> 1) Edit configulation file to specify the features (XPM and so on).

This can be done on the command line with autoconf. i.e.
./configure --with-xpm

It can also optionally be done manually in configure.h

> 	and so on ('xmkmf -a' is enough ?).

Just have configure make the Makefiles.  Imake shouldn't be needed.

> 4) do 'make install'

I have had plenty of problems trying to get Imake to work properly on
commercial Unixes (Solaris and HPUX) where it is the goal of the OS vendor
to force you to buy their development environment.  HPUX doesn't even come
with Imake, and once you find it and install it, it is set up to use HP's
compiler (which isn't included) and it sets up the CFLAGS with a bunch of
non-standard compiler switches.  At least Solaris comes with Imake, but
again it is set up for the commercial compiler.

I have had varying degrees of success with using options to imake i.e.
something like:
imake -DHASGCC=YES
(I don't remember the exact syntax) but nothing compares to a well-written
autoconf setup.

Tony.

---

From: [email-masked] (Todd Fries)
Date: Thu, 23 May 1996 02:33:36 -0500 (CDT)

> that's the misconfiguration of imake :-) Imake SHOULD know the environment.

Sorry.  Not all of us are the sysadmin's of the machines we use.

> Hmm :-) Then, everyone gets X11R6 distribution and make their own X if

perhaps, but I don't have the space on any of my accounts.

> informaiton of $XTOP/lib/config ? or simply kicks imake to use ?

I suggest you be more familar with autoconf before you slam it.

-- 
Todd Fries .. [email-masked] .. [email-masked] .. [email-masked]

---

From: [email-masked]
Date: Thu, 23 May 96 10:58:09 +0100

> (I don't remember the exact syntax) but nothing compares to a well-written
I agree entirely. I compile programs for 6 platforms (SunOS, Solaris, OSF,
HPUX, AIX, Ultrix) and Autoconf'd programs, both X and non-X, almost always
compile straight out of the tar file for all platforms. The same cannot be
said for programs that use Imake. 

--
Kevan

<http://www.ftech.net/~kevan/>

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Thu, 23 May 1996 12:00:25 +0200

>>>>> "Anthony" == Anthony Martin <[email-masked]> writes:

[Lots of good things about autoconf]

I agree completely with Anthony. One more point in favor of
autoconf. Since you write the skeleton of the Makefile(s), it is by
design human readable. This means that, unlike imake-generated
Makefiles, you can hack them if something goes wrong.

Concerning setting up correctly imake, it can be very difficult to do
on some proprietary systems and versions of X11. It is better to fix
fvwm once than to tell a bunch of people to fix their setup.

Jean-Marc.

---

From: まつしたまこと <[email-masked]>
Date: Thu, 23 May 1996 18:50:17 +0900

amartin> Then it isn't so foolish to assume that these are the actual
amartin> locations, it checks to make sure.

GNU autoconf decides libraries and files are exists. Suppose directories
/usr/local/X11R5 and /usr/local/X11R6 are both exist, GNU autoconf can
decide "which version of X to use" ? With imake, you can easily decide
with using which imake (/usr/local/X11R5/bin or /usr/local/X11R6/bin)
is suitable.

Auto detection is great, and GNU autoconf does well I know, but GNU
autoconf is not flexible when a user want to setup a little bit tricky...

amartin> HPUX doesn't even come with Imake, and once you find it and
amartin> install it, it is set up to use HP's compiler (which isn't
amartin> included) and it sets up the CFLAGS with a bunch of
amartin> non-standard compiler switches.  At least Solaris comes with
amartin> Imake, but again it is set up for the commercial compiler.

That's right, but there is no reason to avoid this problem. How about
providing imake environment for HP-UX ? (I heard somebody already
makes this) or providing Packaged Solaris binaries of GCC ? (I heard
this also) ?

Using GNU autoconf is easy, but I think it's not a true solution to
this problem, just a escape...

- -

---

From: まつしたまこと <[email-masked]>
Date: Thu, 23 May 1996 19:49:00 +0900

Hmm..

todd> To a better solution.

If you say so, why not making GNU autoconf configulation for fvwm ?

Using configure is paradise, light use of autoconf is well, and making
cool configure script by autconf is just a nightmare... That's my experience.

- -

---

From: [email-masked] (Todd Fries)
Date: Thu, 23 May 1996 04:36:30 -0500 (CDT)

> autoconf is not flexible when a user want to setup a little bit tricky...

Lemme see:

autoconf:  override with command line switches
imake:     totally re-install and re-configure to get it to work properly

You tell me which is more flexible.

> this problem, just a escape...

To a better solution.

---

From: Kai Grossjohann <[email-masked]>
Date: 23 May 1996 13:29:55 +0200

>>>>> On Thu, 23 May 1996 18:50:17 +0900,
>>>>> =?ISO-2022-JP?B?GyRCJF4kRCQ3JD8kXiQzJEgbKEI=?=
>>>>> <[email-masked]> said:

  Makoto> [...] Suppose directories /usr/local/X11R5 and
  Makoto> /usr/local/X11R6 are both exist, GNU autoconf can decide
  Makoto> "which version of X to use" ? [...]

./configure --with-x\
            --x-includes=/usr/local/X11R6/include\
            --x-libs=/usr/local/X11R6/lib

Or something like that, I forget the concrete syntax.  Works just dandy
for Emacs, at least.

kai
-- 
Life is hard and then you die.

---

From: [email-masked]
Date: Thu, 23 May 96 12:35:20 +0100

>From my own experience I would say that the reverse is true. How easy is
it to the equivelent of the Autoconf:

  ./configure --exec-prefix=/tools/app/fred-1.2 \
              --prefix=/tools/share/app/fred-1.2

When you have multiple platforms, the need to conserve disk space, and the
ability to easily back out of new versions of an application, the above
sort of configuration is needed.

I have found that with most Imake configured programs they insist in
installing directly into your X11 directories, which on our systems
are not writeable by normal users. 
I think a big problem with Imake'd programs is that they don't come with
documentation on how to configure installation locations etc (Fvwm is a
noteable exception here :-) whereas Autoconf one do.

--
Kevan

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Thu, 23 May 1996 10:37:59 -0400

>>>>> "matusita" == matusita  <[email-masked]> writes:

    matusita> If your imake doesn't know all about the development
    matusita> environment, that's the misconfiguration of imake :-)
    matusita> Imake SHOULD know the environment.

Right!  Since we install all of our net-contrib'd X software in
`non-standard' places (i.e. not /usr/openwin/bin on Solaris), one of
the first things I had to do is copy all the OpenWindows imake config
files and hack them up so they'd reflect our environment.  Now that
I've done this, most X programs build fairly painlessly.

-Barry

---

From: まつしたまこと <[email-masked]>
Date: Thu, 23 May 1996 23:46:27 +0900

grossjoh> ./configure --with-x\
grossjoh>             --x-includes=/usr/local/X11R6/include\
grossjoh>             --x-libs=/usr/local/X11R6/lib

I think it is too tired :-) Editing *akefile and execute appropriate
command of what you want. It's simple :-)

Somebody says GNU configure is flexible because of command-line
option, but it's unflexible because of command-line ONLY. Editing
*akefile after 'sh ./configure' is out of the questions :-)

Using GNU configure as a default is easy. But it's less
flexible when we want to use 'site specific' setup.

- -

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Thu, 23 May 1996 10:42:51 -0400

>>>>> "JL" == Jean-Marc Lasgouttes <[email-masked]> writes:

    JL> I agree completely with Anthony. One more point in favor of
    JL> autoconf. Since you write the skeleton of the Makefile(s), it
    JL> is by design human readable. This means that, unlike
    JL> imake-generated Makefiles, you can hack them if something goes
    JL> wrong.

    JL> Concerning setting up correctly imake, it can be very
    JL> difficult to do on some proprietary systems and versions of
    JL> X11. It is better to fix fvwm once than to tell a bunch of
    JL> people to fix their setup.

The thing to do is leave the system config files in place, make a copy
of the config directory into someplace you can edit, then also copy
xmkmf (it's just a script, at least under OpenWindows) so that it uses
the new config files by default.  Then make sure your xmkmf is earlier
in your path.

But you are definitely right that imake config files, and the
generated Makefiles are not humanly readable. :-)  Hacking those
config files is a major pain.

-Barry

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Thu, 23 May 1996 17:45:01 +0200

>>>>> " " == =?ISO-2022-JP?B?GyRCJF4kRCQ3JD8kXiQzJEgbKEI=?=  <ISO-2022-JP> writes:

     > I think it is too tired :-) Editing *akefile and execute
     > appropriate command of what you want. It's simple :-)

     > option, but it's unflexible because of command-line
     > ONLY. Editing *akefile after 'sh ./configure' is out of the
     > questions :-)

Of Course. If you are too tired to use these commands each time, you
can place all the assignments you want in the file config.site, which
will be read by all programs using autoconf. You might argue that it
is as difficult as fixing imake, but I see several advantages:

- you have the choice to use command line or config.site.  

- this will work for non-X programs too.  

- it is much easier to do: once you have found the right options for
  configure, have a look into config.cache and cut and paste the right
  lines in /usr/local/etc/config.site (there are also other places
  that are searched for). That's it!

Jean-Marc

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Thu, 23 May 1996 12:37:07 -0400

>>>>> "PDS" == Paul D Smith <[email-masked]> writes:

    PDS> Imake is dated, crufty technology that's marginally useful
    PDS> for building X... period.  IMHO of course :)

You and I do not disagree on this at all!

---

From: "Paul D. Smith" <[email-masked]>
Date: Thu, 23 May 96 12:28:44 EDT

[[ Form of ... a forest fire! ]]

%% "Barry A. Warsaw" <[email-masked]> writes:

    baw> Right!  Since we install all of our net-contrib'd X software in
    baw> `non-standard' places (i.e. not /usr/openwin/bin on Solaris),
    baw> one of the first things I had to do is copy all the OpenWindows
    baw> imake config files and hack them up so they'd reflect our
    baw> environment.  Now that I've done this, most X programs build
    baw> fairly painlessly.

Sure... as long as you always want to put them in the same place.  What
if you want to put them into _different_ places?  Do you have to go back
and hack up the config files again?  How do you handle switching back
and forth?

I sometimes want to install imake-based apps into the X release
directory, and sometimes into our "global" contrib software directory,
and sometimes other places (our source tree, perhaps, if it's a tool or
something).  It's next to impossible to do this with imake.  I've posted
many queries for help and guidance to the X newsgroups, and received
many "me-too" responses, but as of yet I have not received one _single_
suggestion on a solution.

Imake is dated, crufty technology that's marginally useful for building
X... period.  IMHO of course :)

I'd prefer it if X went to autoconf too: autoconf has one GIGANTIC
advantage over imake that basically makes this entire conversation
silly: autoconf gracefully handles building source for multiple
architectures at the same time, without conflict.  I always do this with
all autoconf packages:

  $ tar xofz package-500.tar.gz
  $ cd package-500
  $ mkdir _sun4
  $ cd _sun4
  $ ../configure --prefix=/usr/global
  $ make

Then, I login to my HP, and do this:

  $ cd package-500
  $ mkdir _hp9
  $ cd _hp9
  $ ../configure --prefix=/usr/global
  $ make

all at the same time, of course.

With imake, I have to build for one, install, clean, then build for the
next, install, clean, etc.  If I find a problem with the first one, I
have to clean out the current one, rebuild everything over.  With
autoconf, I have all the architectures there already built; I just
recompile the one file that changed and relink.

X's symbolic link farm solution is crufty at _best_, and only works with
X--it doesn't translate automatically to all packages which use imake.

(To be fair, it can be tricky writing your autoconf Makefile.in to work
with the multi-architecture feature correctly if you're not familiar
with VPATH, but at least it's supported and there are lots of good
examples).

%% <[email-masked]> writes:

    mm> I think it is too tired :-) Editing *akefile and execute appropriate
    mm> command of what you want. It's simple :-)

Uhh... really, really NOT! :)

What do I edit?  Who knows?  The Imakefile just says
"InstallSimpleCommand()" or some such thing.  No path, no nothing.

What if I want to install it somewhere else?  What if I want it to build
with an install path of /foo/bar, but when I run install I want to stage
it into a directory /local/beta/foo before actually installing it (I do
this all the time)?

    mm> Somebody says GNU configure is flexible because of command-line
    mm> option, but it's unflexible because of command-line ONLY. Editing
    mm> *akefile after 'sh ./configure' is out of the questions :-)

Why?  Makefiles generated by autoconf are trivial to edit for changes
like this--a far sight simpler than editing a postprocessed imake
Makefile, no doubt about that!  Imake generates makefiles with 10 pages
of boilerplate stuff at the beginning, and you can't tell which variable
to change for which path: there seem to be two or more for every
purpose.  I'm constantly searching back and forth through the makefile
trying to figure out where variables got their values from and which one
I should change.

Then half the time the actual make rules at the bottom of the makefile
don't even use the boilerplate variables!  And when they do, they often
use the same variable for so many different things that you can't get it
to do what you want.

With imake, about 70% of the time I end up thinking it'd be easier to
just write my own makefile, and I sometimes do.  With autoconf, I can't
remember _ever_ thinking that, much less doing it.

Autoconf makefiles all have a nice little section at the top like this:

  # Common prefix for machine-independent installed files.
  prefix = /usr/global
  # Common prefix for machine-dependent installed files.
  exec_prefix = ${prefix}

  # Directory to install in.
  bindir = $(exec_prefix)/bin
  # Directory to install the Info files in.
  infodir = $(prefix)/info
  # Directory to install the man page in.
  mandir = $(prefix)/man/man$(manext)
  # Number to put on the man page filename.
  manext = 1

Everything is based off of $(prefix).  Trivial to change the entire
thing by resetting $(prefix), or you can tweak them individually for
greater flexibility.

I usually just override them on the make command line.  E.g., to do what
I mentioned above and stage the installation is trivial:

  $ ./configure --prefix=/foo/bar
  $ make
  $ make install prefix=/local/beta/foo

Done.  I never even bother to _look_ at the makefile.  Plus, autoconf
packages come with some darn documentation (the INSTALL file); almost no
imake packages tell you how to customize the install directories, etc.

    mm> Using GNU configure as a default is easy. But it's less
    mm> flexible when we want to use 'site specific' setup.

I couldn't disagree more.  Imake is unfriendly, inflexible, confusing,
difficult to use even in the simple case, impossible to use for more
complex cases, and _way_ to big and complex for what you get (who needs
all that for a few simple pathname settings and a compiler name for
pity's sake?  Autoconf actually _works_ for its money, producing a
customized config.h file or whatever :)

Autoconf has its problems, but it's far and away the very best choice
out there.

Go ahead, ask me how I _really_ feel! :)

[[ Shape of -- a glacier! ]]

-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 Senior Software Engineer                                   Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
     These are my opinions--Bay Networks takes no responsibility for them.
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: tim werner <[email-masked]>
Date: Thu, 23 May 1996 14:05:03 -0400

>Imake generates makefiles with 10 pages of boilerplate stuff at the
>beginning, and you can't tell which variable to change for which path:
>there seem to be two or more for every purpose.

Right on.

I can only tip my hat to the folks who say imake is usable.  I have
tried and tried to get to where I could even understand how to use it,
much less understand what's really going on.  No effin' way.  Sorry.

tw

---

From: Anthony Martin <[email-masked]>
Date: Thu, 23 May 1996 11:09:31 -0700 (PDT)

> with using which imake (/usr/local/X11R5/bin or /usr/local/X11R6/bin)

This is why configure takes the options --x-includes=DIR and
--x-libraries=DIR so that you can manually override configure.  Yes,
autoconf/configure is quite flexible.  And in the above example, configure
would choose the imake that comes first in your path, so if this is not
what you want, then just override it with the command-line options to
configure.

Tony.

---

From: [email-masked] (Todd Fries)
Date: Thu, 23 May 1996 14:34:24 -0500 (CDT)

> flexible when we want to use 'site specific' setup.

Oh really?  Then what the heck do you call that?  Non-site-specific?

Personally, I am setting up a set of makefiles that when I type
'make packagename' it will download, uncompress, compile, and install
stuff without a single other lift of the finger.

I know, I'm lazy, but hey, isn't that was make is for?

Anyway, I have found it tons easier to give configure command line options
for where I want to install stuff.  Things done with imake I have had
to edit makefiles per application, figure out where it's install
prefix is if there is such a beast in a variable, and perhaps supply my
auto-mated compiler with a patch for the makefile if there isn't.

To me it is tons easier to just do:

./configure --prefix=/abc/software/fvwm-2.0.42/Linux

and then

./configure --prefix=/abc/software/fvwm-2.0.42/solaris

rather than:

cd /abc/software/fvwm-2.0.42/Linux/src/fvwm-2.0.42 
patch -p1 < /abc/software/fvwm.linux.patch
MakeMakefiles

and then

cd /abc/software/fvwm-2.0.42/solaris/src/fvwm-2.0.42 
patch -p1 < /abc/software/fvwm.solaris.patch
MakeMakefiles

And pray that nobody changes the Fvwm.tmpl file, so I don't have
to manually redo the patches.

I think it is becoming quite clear what is an easier solution.

---

From: まつしたまこと <[email-masked]>
Date: Fri, 24 May 1996 11:27:47 +0900

amartin> This is why configure takes the options --x-includes=DIR and
amartin> --x-libraries=DIR so that you can manually override configure.

I want configure to detect which X is used by automatically :-)

Well, the point that I want NOT to use GNU autoconf is "Writing
appropriate configure.in and/or related stuff (to make configure
configure script) is difficult than writing appropriate Imakefile". I
want NOT to force all developer who want to contribute/write a module
for fvwm.

Though configure script is maybe flexible and usable, why only a few
application (except the GNU product) uses GNU autoconf for generating ?
I think many developer want NOT to use GNU autoconf because of difficulty...

- -

---

From: "Paul D. Smith" <[email-masked]>
Date: Fri, 24 May 96 00:14:11 EDT

%% Regarding Re: FVWM: Gnu configure on next realease ???;
%% <[email-masked]> writes:

    mm> I want configure to detect which X is used by automatically :-)

It will... it automatically uses the info for the X that's first in your
path variables.  Same as xmkmf.

    mm> Well, the point that I want NOT to use GNU autoconf is "Writing
    mm> appropriate configure.in and/or related stuff (to make configure
    mm> configure script) is difficult than writing appropriate
    mm> Imakefile". I want NOT to force all developer who want to
    mm> contribute/write a module for fvwm.

Yes, you have a point.  Writing an autoconf configure script is probably
more difficult for a developer than a a simple Imakefile, although
straightforward autoconf environments aren't very complex, really: just
use the samples that come with autoconf... I wrote one for a project of
mine in a few hours, and that was autoconf 1.0 or some such.  It's a lot
better now.

But let's be honest, where do we really want the ease-of-use to come?
For the developer, who is one person and does it once, or for each of
the users, who will do it thousands of times (cumulatively)?

Obviously we'd rather the developer spent a little extra time to save
all the users a lot of heart- and headache.

Once the basic modules are autoconf'd, I can't believe that adding a new
one would be tough at all.  All the modules will use the config.h
generated by the main fvwm configure, rather than re-running configure
themselves, so it's just a matter of copying another module's
Makefile.in and tweaking it... and probably just a variable or two would
change.

    mm> Though configure script is maybe flexible and usable, why only a
    mm> few application (except the GNU product) uses GNU autoconf for
    mm> generating ?  I think many developer want NOT to use GNU
    mm> autoconf because of difficulty...

That may be one reason (although I think those developers are not
looking at the big picture if that's their sole reason).

Another might be that people writing X apps find it easier to use X's
config.  I don't see hardly any non-X apps using imake, really.

The most telling is probably that imake has been around a lot longer and
has a larger presence than autoconf: there're books about it and some
vendors ship system config files by default.  People know about it.

That's no reason to continue using it, though; if that were everyone's
attitude we'd not be using FVWM now :)

Anyway, I think we've beat this subject into the ground.  Cheers :)

---

From: "Stefan 'Stetson' Skoglund" <[email-masked]>
Date: Fri, 24 May 1996 09:34:19 +0200

Hmm, autoconf generated configure is intended to test for features.
For example the absence of getwd, if the system supports shared
libraries, if the system has an ansi c compiler and so on.

This requires that the developer adapts to it ie he/she needs
to use a number of #ifdefs for example.

This would not be necessry if libfvwm provides all modules
with an homogen interface or proxies for functions missing
in the system for example getwd.

The main stumble is ususally signals and its different interfaces.
SunOS4 supports for example both systemV and BSD.
Solaris 2.4 is POSIX and so on.

---

From: Jean-Marc Lasgouttes <[email-masked]>
Date: Fri, 24 May 1996 10:32:29 +0200

>>>>> " " == =?ISO-2022-JP?B?GyRCJF4kRCQ3JD8kXiQzJEgbKEI=?=  <ISO-2022-JP> writes:

    amartin> This is why configure takes the options --x-includes=DIR
    amartin> and --x-libraries=DIR so that you can manually override
    amartin> configure.

     > I want configure to detect which X is used by automatically :-)

Well, it takes the xmkmf which is the first on the path. This is a
good way to find the good X.

     > appropriate configure.in and/or related stuff (to make
     > configure configure script) is difficult than writing
     > appropriate Imakefile". I want NOT to force all developer who
     > want to contribute/write a module for fvwm.

Once the main configure script is written, it can generated a file
Make.rules which contains all the variables parts of the setup. Then
the developper of a module only has to write a module containing a few
lines (mostly the list of object files...).

     > Though configure script is maybe flexible and usable, why only
     > a few application (except the GNU product) uses GNU autoconf
     > for generating ?  I think many developer want NOT to use GNU
     > autoconf because of difficulty...

Well, X applications use imake because we were told it is the right
thing to do. However, I maintain a configure script for an X
application (LyX, a word processor written in C++) and it works well.

Jean-Marc

---

From: Mark Boyns <[email-masked]>
Date: 24 May 1996 09:08:41 -0700

> application (except the GNU product) uses GNU autoconf for generating ?

A better question is why only a few X applications use GNU autoconf.
Here's a few X applications that do use autoconf:

   xarchie, xsession, ImageMagic, gimp, jpeg library, xshisen

> I think many developer want NOT to use GNU autoconf because of difficulty...

But autoconf isn't difficult.  autoconf comes with a program called
`autoscan'.  Here's an excerpt from the Info page:

       The `autoscan' program can help you create a `configure.in' file for
    a software package.  `autoscan' examines source files in the
    directory tree rooted at a directory given as a command line
    argument, or the current directory if none is given.  It searches
    the source files for common portability problems and creates a
    file `configure.scan' which is a preliminary `configure.in' for
    that package.

-- 
Mark Boyns <[email-masked]> <URL:http://www.sdsu.edu/~boyns/>
PGP fingerprint = D3 28 A2 F7 D1 4C F8 EE  BF 7A 11 54 1C E5 6E CC
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: "Randall S. Winchester" <[email-masked]>
Date: Fri, 24 May 1996 16:15:53 -0400 (EDT)

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

---

From: Kai Grossjohann <[email-masked]>
Date: 24 May 1996 23:41:32 +0200

>>>>> On Fri, 24 May 1996 16:15:53 -0400 (EDT), "Randall
>>>>> S. Winchester" <[email-masked]> said:

  Randall> I will personally volunteer to test early releases. I have
  Randall> HPUX, Solaris, SunOS, IRIX, NetBSD, DU (OSF/1), and Ultrix
  Randall> systems I can test both vendor and X11R6 builds against.

FWIW, I'm volunteering, too.  Linux/X11R6 and SunOS 4.1.4/X11R6 (but
the latter will probably change to Solaris/OW in a few months).

kai

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 24 May 1996 17:29:31 -0400

>>>>> "RSW" == Randall S Winchester <[email-masked]> writes:

Hi Randall - I was wondering if you might speak up about this.  :)

I've waited for it to die down a bit before doing so myself.  Now
looks like a good time.

RSW> I think autoconf is a nice thing to work towards.

So do I.

RSW> I have used it is house and it is invaluable once the effort has
RSW> been put in to convert a large application to use configure. Its'
RSW> primary author, David J. MacKenzie, worked for me while a student
RSW> at the University of Maryland, so I would gladly see his work in
RSW> wider use. However every time you muck with the build procedure
RSW> you will interject bugs or problems that will take several
RSW> release cycles to clean up. Look at what has happened to FVWM the
RSW> last many months.

Very true.

RSW> Besides trying to clean up things for the release, the Imake
RSW> configureation has gone through a couple good sized changes. Each
RSW> time things that were fixed before were broke. This will happen
RSW> with autoconf also. This has also slowed down the releses of FVWM
RSW> ( In my opinion ),

Yup, sure has.

RSW> as constant build bugs that are reported with each beta tend to
RSW> keep people from pulling the newest release once they have
RSW> something installed and mostly working. This needs to get fixed.

True.

RSW> Maybe if Chuck had a few "elves" that he could have grab and try
RSW> his releases on several platforms before he publicly announced a
RSW> release we could clean up clean up the obvious bugaboos before it
RSW> was announced.  A number of other lists that I am on do this with
RSW> good success and there products look much cleaner as a result of
RSW> this. Typical there is something like an "fvwm-workers" list,
RSW> where those commited to supporting the product can quickly
RSW> prepare things for release. I do like the open forum of the fvwm
RSW> list though, but think something is in order.

This is probably a good idea.  That is more or less what the mailing
list started as, but now there are probably more 'user' types than
'tester' types on the list, and it could probably be split up.

Jason - how do you feel about adding a third mailing list (not
publically announced or not easily subscribed to perhaps) called
'fvwm-workers' or 'fvwm-beta-testers' or something like that?  Does
this sound like a good idea to you?  I don't really want to impose
upon your hospitality though, so if you don't want the additional
burden, just say so and we'll figure out something else.  I could just
make a mail alias w/ those people who would like to be these testers
and just do it by hand.

RSW> I will personally volunteer to test early releases. I have HPUX,
RSW> Solaris, SunOS, IRIX, NetBSD, DU (OSF/1), and Ultrix systems I
RSW> can test both vendor and X11R6 builds against.

Wow.  That's quite a number of OS'es.  I cover AIX (IBM's X11R5) &
Linux myself.

If I win the lotto this weekend, I'll buy some workstations for home
and test a few more of them myself.  :) Until then, I may just take
you up on your offer.

RSW> If we had a couple/few volunteers for the major OS's and X11's,
RSW> then one of us for each or most OS's and X11's could get back to
RSW> chuck in a sort about of time so as not to slow up his releases
RSW> by more then 1 or 2 days at the most.

Which isn't bad considering it usually takes a month or 2 for me to
get them out anyways. :)

RSW> The result will be better quality control for FVWM.

Most likely.

RSW> There are many nuances with buiding things under X11. There are a
RSW> number of changes from R4, to R5, to R6 and between vendors that
RSW> make it hard to get things right if you do not test them on a
RSW> number of platforms. Autoconf will have to deal with some of
RSW> these same problems. When I started contributing my changes to
RSW> the fvwm configuration, I at first only tested my changes on a
RSW> couple OS's and under X11R6 only. A number of bugs were reported
RSW> then by people who had differnet configurations then I tested
RSW> under. Later I started testing under more platforms and using
RSW> various xmkmf and X11 versions, and the bugs dropped way
RSW> down. One more iteration would probably have stabilized this. The
RSW> decisions was made to make the build more Imake-ish at this time,
RSW> and the changes broke a number of things. Now a couple iterations
RSW> later and we still have one or two cycles go before the build
RSW> process will be release ready.

I'm hoping that this next one will take care of it (basically, that
last patch I just sent out should do it, I think).  BTW - I plan to do
a fair amount of work on the next beta this weekend (since I have
Monday off too) so perhaps I can get it out soon.

RSW> Lets not do this again right now, as there are alot more
RSW> important FVWM things to work on. The current setup will work
RSW> fine for most of us with a couple more turns of the crank.

Definitely.

RSW> Again, I would like to see further beta releases address changes
RSW> to the FVWM code itself, and see the configuration/build process
RSW> stabilized until after FVWM-2.1 is released.

I fully agree with this and have NO intention on changing the build
process again until after 2.1.0 is released.  As you noted, twice was
already too much.

But after that, I'd definitely like to start experimenting with
Autoconf, although other changes (particularly fixes) will obviously
take precidence.  I won't remove Imake at first (perhaps never
depending on how things go) but rather introduce it slowly and try to
make it work both ways if possible.

But I don't see any reason why Autoconf can't be made to work just
fine to configure fvwm.  It may be tricky, but I think in the end
it'll work out much better than Imake has.

RSW> (my 2 cents worth)

Mine too.

Whoops - I'm running late - gotta go!
Chuck

             -- of course, we ARE still in Hell." (Gary Larson)

---

From: Jason L Tibbitts III <[email-masked]>
Date: 24 May 1996 17:59:04 -0500

>>>>> "CH" == <[email-masked]> writes:

CH> Jason - how do you feel about adding a third mailing list (not
CH> publically announced or not easily subscribed to perhaps) called
CH> 'fvwm-workers' or 'fvwm-beta-testers' or something like that?  Does
CH> this sound like a good idea to you?

Yes, I think it's to the point where something like that needs to be done.
List traffic has gone way up in the past three or so months and I think
something needs to be done to get the S/N and Development/FAQ ratios back
up.

I don't have a problem adding another list; actually I expect that it will
reduce the overall volume of mail that I push.  I'm currently experimenting
(somewhat unsuccessfully, but...) with a newer version of the list
software; once that settles down I'll go ahead and work at another list.
I like fvwm-workers myself.

CH> I don't really want to impose upon your hospitality though, so if you
CH> don't want the additional burden, just say so and we'll figure out
CH> something else.  I could just make a mail alias w/ those people who
CH> would like to be these testers and just do it by hand.

It's not a real problem.  A few lines in /etc/aliases and a couple of
mkdir's and cp's.  And a glorious long weekend to do it in, too!
-- 
      Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Todd Fries)
Date: Thu, 23 May 1996 14:27:18 -0500 (CDT)

> I've done this, most X programs build fairly painlessly.

That's what a good sysadmin would do.  Unfortunately not all of us have
such a useful administrator.