Subject: autoconf stuff

From: [email-masked] (Paul D. Smith)
Date: 02 Nov 1998 01:34:04 -0500

First, Steve, can you write a quicky-README for developers on how to
build the distribution, etc. using autoconf/automake (describe that you
(currently) need to run "make all" or similar before attempting "make
dist; give a pointer to make distcheck; etc.) 

Also, I understand why you are checking in derived files (like
configure), but I wonder if that's a bit dangerous?  What if someone
starts using a newer or older version of autoconf?  I can see the other
side, too: you may not want to require every beta tester to have a full
autoconf/automake set to get started.  Just curious as to your thoughts
on this.

-- 
-------------------------------------------------------------------------------
 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: Steve Robbins <[email-masked]>
Date: Mon, 2 Nov 1998 09:54:22 -0500 (EST)

> dist; give a pointer to make distcheck; etc.) 

Sure.  Some of that info is in the README.autoconf file I distributed, but
I'll try to spell it out again here. 

As you observed, all the derived files (the configure script, config.h.in,
and all the Makefile.in's) are checked into the repository. Hence, you
need to know NOTHING about autoconf/automake to check out the sources and
build it.  NOR do you need to install these tools.  You can even hack on
the sources without these tools.

The ONLY time you need the tools is if you have to change a makefile or
the configure script.  Or if you want to build a tar file for
distribution.

Changing a Makefile
-------------------

First of all, NEVER edit anything named Makefile, or Makefile.in.  These
are both derived from the corresponding Makefile.am.  The most common
reason for editing is to change the list of sources. 

Steps: 1. edit foo/blah/Makefile.am
       2. re-run "make" from the top of the build directory

Step 2 will take care of rebuilding the Makefile.in and Makefile from your
changed Makefile.am.

Makefile.am has a simple format, basically:

	bin_PROGRAMS = fvwm2

	fvmw2_SOURCES = blah.c blah.h foo.c foo.h ...

Notice that you have to add all files, C-code *and* headers, to the
_SOURCES line.  This is vital, because this is the list of files that are
packed into the distribution.  If you leave one out, nobody will be able
to build the distributed tar file!

Changing configure.in
---------------------

The most common reason to do this is to change the version string.  If
you're editing it for any other reason, I will assume you know what you're
doing.

Steps: 1. edit configure.in, and find the line containing
          AM_INIT_AUTOMAKE(fvwm, x.y.z) at the top of the file
       2. change x.y.z to the new version string
       3. re-run "make" from the top of the build directory

Step 3 will take care of rebuilding the configure script, and usually all
the other Makefiles.

Building a distribution
-----------------------

By this, I mean the file "fvwm-x.y.z.tar.gz".

Steps: 1. make sure you have XPM and a C++ compiler
       2. configure with the flag --enable-extras
       3. make
       4. make distcheck
       5. ensure that you see the message 
	  "fvwm-x.y.z.tar.gz ready for distribution"
          before uploading the tar file somewhere

One thing I've learned the hard way: 

	You have to configure with ALL THE OPTIONAL SUBDIRECTORIES
	in order to build a distribution!

In short: this means you need Xpm, and a C++ compiler, AND you have to
configure using the flag --enable-extras.  The reason for this is that a
couple of subdirectories are only built when using Xpm (xpmroot, for
example) or C++ (extras/FvwmConfig).  It is fine for end users to not
build these.  However, the distribution-maker has to have all the
directories enabled, else the files don't make it into the distribution
tar file. 

Similarly, you need to have actually built everything before packing the
distribution, hence step #3.  Among other things, this puts into the
Makefile.in's the proper dependency information. 

Step 4 will create the tar file, then unpack it and attempt a build &
install (to a scratch directory, not /usr/local).  This makes sure that
you really DID include all the files necessary to build the package into
the tar file. It may be hard to appreciate how useful this is, until it
has reminded you that you forgot file "foo.h" in some _SOURCES line.  But
trust me, it will save your bacon in this way some day!

> autoconf/automake set to get started.  Just curious as to your thoughts

Hmm.  I suspect that if anyone is using a different version of
autoconf/automake that generates INCORRECT Makefile.in's, it will be
discovered and rectified rather quickly.  Certainly before any
distribution is made. 

I suppose one problem is if developers A and B use different versions of
automake, say, and both generate CORRECT but different Makefile.in's from
the same Makefile.am. Then the Makefile.in would keep getting checked in
unnecessarily.  That would be a waste of space in the repository and
generate unnecessarily large diffs.  This is annoying, certainly, but
perhaps not a fatal flaw.

Maybe we could just agree on using a common version of autoconf and
automake?  Since the latter hasn't been updated in years, it would be
surprising to find someone with an older version.  But I hear it is being
maintained again, so newer versions are a possibility.  Automake is also
actively maintained, though, and it is more likely to be the culprit in
generating the Makefile.in's.  I'm using 1.3b.

As everything is, it's a tradeoff against not requiring everyone to have
auto*.  I think that benefit is worth the risk, but I have no real
experience with this in the real world.  Do other groups find this a huge
problem?  Are there other problems with checking in derived files that
I've overlooked? 

--
Steve Robbins                              <[email-masked]>

If I had a rocket launcher, some son of a bitch would die.

---

From: [email-masked] (Paul D. Smith)
Date: 02 Nov 1998 12:55:11 -0500

%% Steve Robbins <[email-masked]> writes:

  >> dist; give a pointer to make distcheck; etc.) 

  sr> Sure.  Some of that info is in the README.autoconf file I
  sr> distributed, but I'll try to spell it out again here.

Sorry, I didn't notice that file.  I meant something in the dist itself,
just as you have it, not necessarily to the mailing list (although
that's handy too :).

Can I suggest: (a) it be renamed to DEVELOPERS or README.devel or
something, and (b) you rework it to put the "how to" stuff at the top
and merge in some of the details you provide below, and put the history
of changes, etc. at the bottom for historical purposes--in a release or
two, after it becomes second nature, no one will probably be too
interested in how the conversion was done initially :)

You might even consider not distributing it with fvwm proper; I guess it
depends on whether we expect people doing active development on fvwm to
have CVS access or not.  Obviously anyone creating distributions will
have it :)

  sr> Maybe we could just agree on using a common version of autoconf
  sr> and automake?  Since the latter hasn't been updated in years,
                               ^^^^^^ former?
  sr> it would be surprising to find someone with an older version.  But
  sr> I hear it is being maintained again, so newer versions are a
  sr> possibility.

Newer versions are absolutely on the near horizon.  Definite plans have
been announced on the autoconf lists for the 2.13 release.  I think
there's an anon-CVS repository for autoconf hosted at Cygnus (where
automake is), too.

Note that both automake and autoconf allow you to specify a minimal
version of tool and will fail if you try to use older versions of
autoconf or automake with those files: you should add this line to your
configure.in:

  AC_PREREQ(2.12)

and this line to Makefile.am (at least the top-level one):

  AUTOMAKE_OPTIONS = 1.3

(not sure if you can put 1.3b in there?)  This will provide some minimal
sanity-checking.  See the relevant docs for more details.

  sr> As everything is, it's a tradeoff against not requiring everyone
  sr> to have auto*.  I think that benefit is worth the risk, but I have
  sr> no real experience with this in the real world.  Do other groups
  sr> find this a huge problem?  Are there other problems with checking
  sr> in derived files that I've overlooked?

I don't know; there was just a long discussion of this on the
autoconf/automake lists.  I just thought I'd raise the issue.

I, personally, don't check in derived files into the GNU make
repository.  But I don't expect anyone to be building that except
someone familiar enough with things to get it working.  GNU make is not
really a "bazaar" development effort at the moment, I'm the only one
changing files :).