Subject: autoconf problems

From: /users/domivogt <[email-masked]>
Date: Wed, 4 Nov 1998 10:16:35 +0100

Here is a list of problems I had with autoconf. If any
of these have already been posted/resolved, please
ignore them. (On SuSE Linux 5.3)

- FvwmAudio does not build.
  I have HAVE_RPLAY set, but RPLAY itself is nowhere
  defined. Thus building FvwmAudio fails.

- FvwmEvents does not build.
  Same reason as for Audio.

- Duplicate include path's
  The gcc line has always '-I. -I.' and most of the time
  '-I.. -I..'. Also there are some extra spaces before
  '-g'.

- Is is slow!
  I estimate it compiled 50% faster with Imake.
  Probably related to next one.

- Is is HUGE!
  All the debug info makes it factor 5-10 larger.
  Should not compile with debug in the distribution if
  you do not explicitly request so. Installing does not
  strip the executables either (again if you do not use
  a special target).

- Make whines once that it'd rather use automake (as a
  warning). Can't reproduce this anymore, but if that
  can be removed this should be done.

Overall the output is a bit wild. Not what I am used to
when using autoconf. This should be cleaned up.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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: Wed, 4 Nov 1998 08:56:55 -0500 (EST)

Hi Dominik,

>   Same reason as for Audio.

You sure this is automake-related?  I checked fvwm-2.0.46 and RPLAY is
nowhere defined there either!  I don't have the library, but from this
code in FvwmAudio.c, I assumed it was a type defined in the header: 

	#ifdef HAVE_RPLAY
	/* define the rplay table */
	RPLAY   *rplay_table[MAX_MESSAGES+MAX_BUILTIN];
	#endif

This is the *only* place RPLAY is used in any file of 2.0.46.

>   '-I.. -I..'. Also there are some extra spaces before

This is cosmetic; nothing to worry about.
 
>   Probably related to next one.

Are you talking about the configure step or the compile step?  

I'm a little surprised that compilation should be so much slower with
autoconf-generated Makefiles compared to imake-generated ones. Are the
Makefiles themselves so much bigger?
 
>   strip the executables either (again if you do not use

What is huge?  The executables or the makefiles?

If huge executables is the problem, then you have to change CFLAGS when
you build, since they default to debugging.  This is a GNU convention, and
one I'd rather not change.  Just do "make CFLAGS='-O4'" instead of make.

Same with install/install-strip: it's a convention for GNU packages. 
People expect them to work this way. 
 
>   can be removed this should be done.

If Automake.in is out-of-date with respect to Automake.am, the makefile
rules try to rebuild it.  (Same with config.h.in, and the like).  This, of
course, requires automake to rebuild.  If you do NOT have automake, you
get this warning, and the offending file is "touch"ed (so you only get the
warning once).  

If you have not changed any of the Makefile.am's, just ignore this.  If
you have, you need automake and autoconf to rebuild things properly.

> when using autoconf. This should be cleaned up.

I need some examples.

--
Steve Robbins                              <[email-masked]>

I'm a member of the Elvis Death Cult.

---

From: /users/domivogt <[email-masked]>
Date: Wed, 4 Nov 1998 15:19:02 +0100

> nowhere defined there either!

I could compile 2.0.46 and 2.0.47x without that problem.
It occurs since autoconf is in, but I'm not sure that is
the reason.

> This is cosmetic; nothing to worry about.

This should still be cleaned up someday. Looks not very
professional.

> Are you talking about the configure step or the compile step?  

Compiling.

> Makefiles themselves so much bigger?

The reason might be all the degug info.

> What is huge?  The executables or the makefiles?

The executables.

> one I'd rather not change.  Just do "make CFLAGS='-O4'" instead of make.

Ahem, I never had to edit the CFLAGS in the Makefiles in any autoconf'ed
software to turn debug off. That can't be the standard.
 
> People expect them to work this way. 

No, I don't and have never seen software that is 5 to 10 times
larger after building than the stripped executables. It is usually
only a few k that can be stripped. At the moment, the fvwm2
executable is >1meg after building and 169000 bytes when
stripped. That *can't* be the default.
  
> I need some examples.

Forgot them at home. Tomorrow I should have them with me.

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Wed, 04 Nov 1998 09:27:57 -0500

> Are you talking about the configure step or the compile step?  

The configure step is a real challenge for my home Sparc 1+, but
I'm not complaining.  For me the advantages outweigh the slowdown.

> Makefiles themselves so much bigger?

I didn't  see  any difference for compiles,  except  that it used  the
flags "-g -O2", which I started to override on my home machine.

I haven't figured out how to exclude  man pages from the install step,
so installs  are  a lot slower  for  the whole directory.  (I  haven't
looked in the makefiles, so I probably shouldn't be mentioning it.)

> you have, you need automake and autoconf to rebuild things properly.

Perhaps a note about  this in INSTALL.fvwm is in  order.  It does sort
of look like somethings wrong if you don't  understand much about this
stuff.

--
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: Dan Espen <[email-masked]>
Date: Wed, 04 Nov 1998 09:44:53 -0500

/users/domivogt <[email-masked]> writes:
> > > - It is HUGE!

I think it is.  Don't forget these GNU folks have  a compiler that can
optimize and  debug at the same time  and it is  my understanding that
all  that symbol information that makes   the executables huge doesn't
really affect the working set (memory use) of the programs.

On the other hand, the fvwm2 project doesn't really get that many core
dump reports.  (I know, 10 seconds out of my mouth, and I'll be proved
wrong.)

I suggest we highlight this change when we put together the NEWS for
this release.

---

From: /users/domivogt <[email-masked]>
Date: Wed, 4 Nov 1998 15:58:00 +0100

> really affect the working set (memory use) of the programs.

Yup, I have the same compiler. What do you want to say with this?
And perhaps it might be a standard, but I have never seen a software
that is this bloated with debug info. Never. GNU standards may be
good usually, but there are exceptions.

> I suggest we highlight this change when we put together the NEWS for

So what is your opinion? Taking -g out or not?

Bye

Dominik

---

From: [email-masked]
Date: Wed, 4 Nov 1998 10:08:44 -0500 (EST)

> So what is your opinion? Taking -g out or not?

How about:

	./configure --with-debug
		(compile with -g)
	./configure --with-full-debug
		(compile with "-DDEBUG -g")

This will allow people to determine how they want to build it, with
about 6-8 additional lines needed in configure.in.

Or, you can do what most GNU tools do (nothing) and have the user use
one of the following for the same effects as the above:

	CFLAGS=-g ./configure
	CFLAGS="-DDEBUG -g" ./configure

It's just a simple matter of getting people used to the new way of
building.  Autoconf is actually quite versatile.

Of course, I'm used to this... on Digital Unix, DEC C is usually
superior to gcc, so I'm constantly passing at least:

	CC=cc CFLAGS=-O2 ./configure

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: Dan Espen <[email-masked]>
Date: Wed, 04 Nov 1998 10:12:31 -0500

> Yup, I have the same compiler. What do you want to say with this?

I'm trying to justify the GNU "default" behavior?
On the other hand, I just did a quick look thru some of the things
I've installed with "configure" and I see either default.

> So what is your opinion? Taking -g out or not?

If this  "automake" tool will only  create a configure file  with '-g'
then I vote for no manual overrides and going with '-g'.  If we get to
have a choice, I'll vote for staying with our old default of '-O'.

The rational for "no change" is, I haven't seen the problem that '-g'
will cure.

---

From: Steve Robbins <[email-masked]>
Date: Wed, 4 Nov 1998 10:14:55 -0500 (EST)

> It occurs since autoconf is in, but I'm not sure that is

I claim it cannot be the reason.
 
> This should still be cleaned up someday. Looks not very

I should have pointed out that it is only because you build in the source
tree that you see duplicated -I flags.  If you build in another directory,
you'd see two different include flags. 

For instance, one of the "-I."  is added by automake (in case there are
built headers in that dir, I guess) an the other comes from "-I$(srcdir)",
to pick up headers in the sources.

To expand on this last point, suppose foo.c includes foo.h.  You would
normally do

	#include "foo.h"

in foo.c.  Fine and dandy if you are compiling in the directory that holds
foo.c and foo.h.  

But automake builds makefiles that can compile from *any* directory.  This
is a great win for people with heterogenous networks: you can do parallel
builds from the same source tree into different directory hierarchies.  It
does, however, mess with the #include statements.  

So what happens is that after a configure, the Makefiles built have a
$(srcdir) variable that points to the original source directory, and the
compile line has "-I$(srcdir)" to take care of the #include "foo.h"
situation described above.

However, there is also the possibility that foo.h is a *derived* file from
foo.h.in (as config.h is).  This derived file must be written into the
build hierarchy rather than the source hierarchy, of course.  I think the
reason that automake-generated makefiles also include a "-I." on the
compile line is because some compilers will fail to find foo.h if it is in
not in the directory with foo.c. 

If the build is in the source tree, then srcdir=. and you have the
phenomenon observed with the repeated -I. -I.  The -I.. has a similar
explanation. 

So, whether you believe it or not, this is a standard feature of
automake-generated Makefiles!

> software to turn debug off. That can't be the standard.

Look again.  It *is* the standard.  

It may not be the case that all GNU software comes with
standards-conforming Makefile.in's.  However, automake-generated
Makefile.in's ARE standards-conforming. 

And no, you don't need to edit the Makefile.  You simply override it on
the command line:

	make CFLAGS=....
  
> stripped. That *can't* be the default.

The size of the symbol table in the executable is irrelevant.  That's a
function of your compiler. 

Whether you believe me or not, the fact is that using "-g" by default is a
GNU standard.  Here are two relevant quotes from their standards.info: 

------------------------ standards.info #1 -----------------------------

   Do include the `-g' option in `CFLAGS', because that is not
*required* for proper compilation.  You can consider it a default that
is only recommended.  If the package is set up so that it is compiled
with GCC by default, then you might as well include `-O' in the default
value of `CFLAGS' as well.

   Put `CFLAGS' last in the compilation command, after other variables
containing compiler options, so the user can use `CFLAGS' to override
the others.

------------------------ standards.info #2 -----------------------------

   All GNU programs should have the following targets in their
Makefiles:

`all'
     Compile the entire program.  This should be the default target.
     This target need not rebuild any documentation files; Info files
     should normally be included in the distribution, and DVI files
     should be made only when explicitly asked for.

     By default, the Make rules should compile and link with `-g', so
     that executable programs have debugging symbols.  Users who don't
     mind being helpless can strip the executables later if they wish.

`install'
     Compile the program and copy the executables, libraries, and so on
     to the file names where they should reside for actual use.  If
     there is a simple test to verify that a program is properly
     installed, this target should run that test.

     Do not strip executables when installing them.  Devil-may-care
     users can use the `install-strip' target to do that.

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

[To hedge my bets, this is from a document "Last updated 9 September
1996".  It is possible, though unlikely, that they have changed their
minds since then.]

When I was dead, I wore a strong perfume.
When I was dead, I never left the room.

---

From: [email-masked] (Paul D. Smith)
Date: 04 Nov 1998 10:30:25 -0500

>> This is cosmetic; nothing to worry about.

  dv> This should still be cleaned up someday. Looks not very
  dv> professional.

The duplicate paths can't be cleaned up.  They're an artifact of the
ability to compile in remote directories: if you configure in a remote
directory one of those will stay "-I." and one will change to be
"-I../fvwm" or some pointer to the source directory.

There's no way (in portable make) to condense these into one.

As for the extra spaces, they're caused by empty variables:

  $(CC) $(CPPFLAGS) $(CFLAGS) $(myCFLAGS)

etc.; whenever one of those variables is empty you get two spaces
together (before and after the empty variable value).

I think it's not worth worrying about this.  I can't imagine anyone
really cares, as long as it compiles :).

  >> If huge executables is the problem, then you have to change CFLAGS
  >> when you build, since they default to debugging.  This is a GNU
  >> convention, and one I'd rather not change.  Just do "make
  >> CFLAGS='-O4'" instead of make.

  dv> Ahem, I never had to edit the CFLAGS in the Makefiles in any
  dv> autoconf'ed software to turn debug off. That can't be the
  dv> standard.

You never edit the makefile; you override it on the command line.  There
are (at least) three ways to do this:

 a) Set CFLAGS during the configure run, like this:

      $ CFLAGS=-O2 ./configure ...

    This sets the default CFLAGS value to "-O2" in the makefile.

 b) Set CFLAGS on the make command line, like this:

      $ ./configure ...
      $ make CFLAGS=-O2

    You have to remember to do this every time you run make, of course.

 c) Create a config.site file containing site-specific overrides you
    always want for all autoconf packages, and set CFLAGS as you like
    it there.  See the INSTALL file for details on this one.

    This is what I do.

All GNU autoconf'd packages _always_ use a default of debugging on.
Always.  Configure checks to see of -g works with -O, and if so it uses
both but if not it prefers -g.

This argument comes up every couple of months on the Linux newsgroups,
for example, and every time it's decided to keep this as the default.
You can go check the archives for more reasoning.  If you've used an
autoconf package that doesn't set -g by default, it's not GNU-compliant
(what package was it?)

Debugging isn't really that big a deal.  It shouldn't make the build
much slower, since the symbol table is always available during the
compile anyway, although note that -O, esp. higher levels, definitely
slows down the build.  Although the binaries are a lot bigger, that
extra space is symbol table info only and not loaded into memory when
the app runs.  The only thing you really lose is disk space.

You might compare the compilation options (-fno-strength-reduce or
whatever) that you used to get with Imake to the ones you get with
autoconf, and use CFLAGS settings as above to make them similar or
identical.  Also, actual timed build differences would be interesting:
it may well be a makefile issue rather than a compile issue.  For
example, remember that autoconf makefiles from CVS keep dependency info
up-to-date automatically all the time, rather than requiring a "make
depend", so that might make a difference during the build.

I agree that the install-strip option should be documented prominently.

  >> People expect them to work this way. 

  dv> No, I don't and have never seen software that is 5 to 10 times
  dv> larger after building than the stripped executables. It is usually
  dv> only a few k that can be stripped. At the moment, the fvwm2
  dv> executable is >1meg after building and 169000 bytes when
  dv> stripped. That *can't* be the default.

Yes, it is, and yes, it's normal.  If other apps you've used don't have
that much difference between stripped and non-stripped versions, that
merely means they don't have that much symbol table info.  GCC
especially adds lots more symbolic debugging info than some other
compilers (this is a _good_ thing :).

I think the single best thing about autoconf is that it's a _standard_.
It's important that we stay as close as possible.  This doesn't mean
we all have to like every aspect of it, and one of the great things
about this standard is that there are so many ways to customize it.  But
I feel it's very important to leave the "as-shipped" version just as
everyone will expect it.  Making changes to do what we like may well
mess up _others'_ expectations and their customizations.

My $0.02.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel 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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 04 Nov 1998 10:48:40 -0500

%% Regarding Re: autoconf problems; I wrote:

  pds> All GNU autoconf'd packages _always_ use a default of debugging on.

Oops, meant "automake'd" here :)

Automake-generated Makefile.in files follow the GNU coding standards.
If you roll your own Makefile.in to use with autoconf those might not,
of course.

---

From: [email-masked] (Paul D. Smith)
Date: 04 Nov 1998 10:54:00 -0500

%% [email-masked] writes:

  lg> How about:

  lg> 	./configure --with-debug
  lg> 		(compile with -g)
  lg> 	./configure --with-full-debug
  lg> 		(compile with "-DDEBUG -g")

I really don't think this is necessary.  As you point out, there are
well-known and standard ways of making these changes already (we should
probably document using -DDEBUG though).

One of the strong recommendations on the autoconf groups is to use
_fewer_ configure options, not more.  As few as you can get away with :).
The more there are the more confusing it gets.

I already wish we didn't have the individual --with-*-includes and
--with-*-library and instead just had one "--with-dir-prefix" or
something :).

Hmm, I see there's already an --enable-debug-msgs option, that appears
to set this:

  #define FVWM_DEBUG_MSGS 1

What's the relationship of this to the normal DEBUG option used by
modules, etc.?  Shouldn't there be only one #define, or do they denote
different "levels" of debugging (and if so, shouldn't this be
controllable at runtime somehow?)

---

From: /users/domivogt <[email-masked]>
Date: Wed, 4 Nov 1998 16:59:44 +0100

*Sigh*

OK it is the standard and so on.

I don't care if the additional info is a few % (perhaps 50)
of the original executable which it usually is. But in our
case we are talking about a ratio of of 15% code vs 85%
debug info (=800k) and in some modules it is even worse.

Whoever compiles for himself will be delighted to get megs
of dead data dumped on his disk. Yes, we can write it in
the README, but everybody will be wanting to strip it
anyway (except a few freaks perhaps). So why don't we
put that additional step in the setup so people do not
have to do it themselves.

And in the end I see not the slightest gain in clinging
to that GNU standard. The people that know these
standards or have noticed them will be able to compile
with debug info anyway. We ignore other standards too,
so where is the problem (or are we indenting out code
by the GNU conventions? And we wouldn't want it as it
would cause lots of unnecessary work).

Bye

Dominik

---

From: /users/domivogt <[email-masked]>
Date: Wed, 4 Nov 1998 18:58:33 +0100

On Wed, Nov 04, 1998 at 10:14:55AM -0500, [email-masked] wrote:
> > > >... 

Was RPLAY used in some file in 2.0.46? The new thing seems to be
that configure finds my rplay lib and sets HAVE_RPLAY. The old
Imake didn't do that so I had no problem.

So, what can we do to fix this?

Bye

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Wed, 4 Nov 1998 23:32:10 -0500 (EST)

On Wed, 4 Nov 1998, /users/domivogt wrote:

> Was RPLAY used in some file in 2.0.46?

Yes, in FvwmAudio, just as it still is.

> The new thing seems to be

Configure using --without-rplay-library

First, we take Manhattan, then we take Berlin.

---

From: [email-masked]
Date: Wed, 4 Nov 1998 19:30:43 +0100

> Configure using --without-rplay-library

Is that what you really think? Ignore build problems and
just tell people to not use the features?

I found out what the problems were:

a) FvwmEvents.c and FvwmAudio.c evaluated HAVE_RPLAY
   before config.h was included (i.e. before it was
   set), so the rplay header was not included.

b) The Makefile.in for FvemEvents did define the rplay
   library but did not link with it.

I'll commit the patches today.

Dominik

---

From: Steve Robbins <[email-masked]>
Date: Thu, 5 Nov 1998 03:36:41 -0500 (EST)

> Imake didn't do that so I had no problem.

I thought you meant that you hadn't defined HAVE_RPLAY in your Imakefiles. 
I interpreted this to mean that you don't have a working rplay library. 
 
>    set), so the rplay header was not included.

Ah, right.  So I was mistaken also in saying that the problem was not
caused by autoconf.  My apologies. 

The include for config.h should be the first thing in all files.  This
currently isn't the case; I am moving the include line as I come across it
during cleanup.  

I should systematically check for this problem.  But in the meantime:

	anyone editing stuff -- particularly modules and extras -- please
	ensure that #include "config.h" is the first include in the file. 
	Thank you.

> I'll commit the patches today.

OK.  Don't forget that it is Makefile.am that you should edit, and you'll
need automake & autoconf to rebuild the Makefile.in.

---

From: [email-masked]
Date: Wed, 4 Nov 1998 20:24:28 +0100

> Sorry Dominik, I misunderstood.  When you said:

OK, perfectly reasonable. In fact I am hardly reading all

> caused by autoconf.  My apologies. 

Yes it was in part caused by autoconf, but don't blame yourself
for things others sis wrong. This was already in 2.0.46.

> need automake & autoconf to rebuild the Makefile.in.

Uh, before I mess things up, could you do this? I just copied
the lines containing rplay from the FvwmAudio Makefile.in to
the one in FvwmEvents.

Bye

Dominik

---

From: [email-masked]
Date: Wed, 4 Nov 1998 20:26:40 +0100

>   Probably related to next one.

I have a statistic for this now (133MHz Pentium):

  complete make in 2.0.47d:  245s
  complete make in 2.1.0:    391s  (plus 7s for FvwmAnimate)
  ----------------------------------------------------------
                           + 146s

  That is 60% longer (191s and 70% if "./configure" and
  "xmkmf && make Makefiles" are taken into account). Since
  FvwmAnimate is not in 2.0.47d I didn't count that.

Bye

Dominik

---

From: [email-masked]
Date: Thu, 5 Nov 1998 12:21:02 +0100

> when using autoconf. This should be cleaned up.

I take that back. It's ok.
 
Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 05 Nov 1998 09:02:07 -0500

%% [email-masked] writes:

  dv> On Wed, Nov 04, 1998 at 10:16:35AM +0100, [email-masked] wrote:

  >> - Is is slow!  I estimate it compiled 50% faster with Imake.

  dv> I have a statistic for this now (133MHz Pentium):

  dv>   complete make in 2.0.47d:  245s
  dv>   complete make in 2.1.0:    391s  (plus 7s for FvwmAnimate)
  dv>   ----------------------------------------------------------
  dv>                            + 146s

  dv>   That is 60% longer (191s and 70% if "./configure" and
  dv>   "xmkmf && make Makefiles" are taken into account). Since
  dv>   FvwmAnimate is not in 2.0.47d I didn't count that.

Did you run the "make depend" step for Imake?

If not you should probably be comparing the build times for the
distribution (after a make dist) vs. the Imake build times.  As I
mentioned yesterday, the "developer's builds" do automatic dependency
updates.  I'd be interested to see how quickly a dist compiles (try
grabbing the 2.1.0 tarball and compiling that).

Still, that seems long.  What are the flags for the compiler in the two
builds?  Does compiling with the same CFLAGS in autoconf as in Imake
cause the build times to converge?

I'm still betting the increased build time is due to the process
(makefiles, etc.) rather than the compiler options.

---

From: [email-masked]
Date: Tue, 17 Nov 1998 12:47:46 +0100

>   complete make in 2.1.0:    391s  (plus 7s for FvwmAnimate)

Finally I was able to rerun the performance test with the 2.1.1
distribution:

  configure  :  68 sec
  make       : 260 sec
  FvwmAnimate:   6 sec
  --------------------
  total      : 334 sec

This is only a little slower that 2.0.47d and may as well be
caused by the additional code :-)

Bye

Dominik