Developers of Sympa

[Guillaume Rousse <address@concealed>]

Olivier Salaün a écrit :
>>> - define software version inside configure.ac directly
>>>     
> Currently we are maintaining in a separate .version file.
> This file is later used to
> 
>   1. include the current version in Version.pm
>   2. compare installed version and to-be-installed versions during an
>      upgrade and print significant changes during the "make install"
>      (via the important_changes.pl script)
> 
> It was convenient to simply update this .version file while preparing a
> new Sympa release, however we might change our habits if needed.
> 
> Could you please explain why putting the Sympa version number in
> configure.ac is a required change ?
I'm not really sure it is required (you may try to run 'make dist' with
current system, and see if genereated archive has correct version), but
I'm sure it's simpler :) Autoconf automatically define a VERSION
variable for you (provided AC_INIT has the correct value), and automake
automatically substitute its values in all makefiles (provided you don't
use static makefiles, of course). If you have all your variables defined
in your makefile, there is no point sourcing external files to get its
value anymore.

For the Version.pm case, this is the classical way to produce it from a
Version.pm.in template file:

Version.pm: Makefile $(srcdir)/Version.pm.in
        rm -f Version.pm
        sed -e 's,@VERSION\@,$(VERSION),g' \
                $(srcdir)/Version.pm.in > Version.pm

The dependency on Makefile itself ensure the file will be rebuild if the
makefile get generated again, by a new configure run, for instance.

>>> - use current AC_INIT and AC_OUTPUT syntax
>>> - define autoconf 2.59 as minimal version
>>> - wrap long lines
>>> - use AC_HELP_STRING for formatting options help output
>>> - make all binaries tests use the same logic, meaning no default value,
>>> and only look in PATH if no value given by user
>>> - don't call AC_SUBST for variables set through AC_PATH_PROG (done
>>> implicitely)
>>>     
> ok
>>> - don't put explicit substitutions targets in Makefile.am, automake does
>>> it automatically
>>>     
> Can you explain?
In your configure.ac, you define some substitutions with AC_SUBST macro,
that will be performed in all templates files declared in
AC_CONFIG_FILES macro.

When you're using autoconf only, you have to manage those templates
yourself, and ensure there is a target inside for each of those
substitution, using the @VARIABLE@ syntax, otherwise the substitution
won't have any effect.

When you're using also automake, you don't have to worry anymore, as
automake will create those makefile.in from makefile.am for you, and
automatically add a @FOO@ target for each existing variable.


>>> - removal of AM_MAINTAINER_MODE in configure.ac (it prevent automatic
>>> makefile rebuild/configure re-invocation)
>>>     
> ok
>>> The second one (use-automake-correctly), bring real change. It is not a
>>>  finished jobs (too many issues to discuss), but it shows how automake
>>> is supposed to be used. So:
>>> - removal of all targets already defined by automake (install, all,
>>> etc..)
>>> - removal of all recursion targets (makedoc, makeman,...)
>>>     
> This seems to be a legitimate change, however note that it requires a
> way to ensure we don't loose any targets, ie lots of testing.
Absolutly.

>>> - conversion of all static Makefile in src and doc trees to Makefile.ams
>>> - definition of SUBDIR variable in top-level, src and doc subdirs
>>> Makefile.am
>>> - definition of primary targets in those makefile, as foo_BAR variables,
>>> where foo is the installation directory, and BAR the type of the file to
>>> install
>>>     
> ok
>>> - definition of EXTRA_DIST and CLEANFILES variable to ensure make clean
>>> and make dist will work as expected
>>>     
> Can you please explain which files will be declared as EXTRA_DIST?
automake know which files to distribute, for all kind of build target it
know how to handle. For instance, if you have a binary program, it knows
it has to distribute its source, and not the resulting binary, so you
don't have to define anything. For other kind of content for which it
doesn't have any clue, you have to help him, using EXTRA_DIST variable.
In particular, DATA and SCRIPTS are not distributed by default, as they
can be generated.

More details here:
http://www.gnu.org/software/automake/manual/automake.html#Dist

The same apply to cleaning files.

>>> - use a standard in-place substitution system for variables defined by
>>> configure process, as per
>>> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/autoconf.html#SEC24
>>>
>>>     
> The current use of the subst.pl script is pretty satisfactory ; it's
> flexible and the script also allows us to do additional changes like
> commenting do_log() calls that can be skipped (performances issue). The
> only drawback of this substitution process (appart its non standard
> character) is that we need to set lots of (error-prone) environment
> variables in Makefiles before each call.
> The new substitution system that you refer to seems less flexible (you
> need to define a twisted sed expression in the Makefile and extend this
> engine for each new variable) and seems to oblige us to add the '.in'
> extension to perl modules, which is not convenient to us.
Well, there are two points there.

The first one is to when to perform substitution. What you do here is to
actually generate perl scripts and modules after installing them,
directly in their installation directories. This is clearly a deviation
from the expected behaviour of 'build first, then install'. It's
difficult to tell how it is bad exactly, but for instance it prevent you
from testing them locally without installing them, including running
non-regression tests. It also extend 'make install' actions, usually
done under root identity, which may be dangerous. And if any failure
occurs, chances are high you'll leave unwanted files in installation
directories, for instance (I've seen this with emacs bytefile
compilation in ocaml installation process, for instance, causing great
packaging pain). So, I'd rather stick with the expected behaviour.

Once you admit you have to have to achieve those substitution in the
build directory, you have to use either different filenames, or
different directories (harder, and won't work with autotools ability to
use distinct build and source trees) to differentiate source templates
from generated files. The use of .in extension is not mandatory, it's
just consistent with Makefile.in -> Makefile conversion when running
configure script.

The second is how to perform the substitution. I personnaly find the
centralized make-driven way more simple. Yes, substituting a tons of
different files is painful. Hence my suggestion of moving all your
variable in a single Constant.pm.in instead of spreading them around 10
different ones.


>>> - drop all reference to custom variables in configure.ac for those
>>> directories defined in GNU's standards
>>>     
> Can you precise which are these custom variables?
All your *DIR variables. Most have direct equivalence for an already
defined variable (BINDIR -> bindir), other don't (CGIDIR).

>>> - drop non-standard /home/sympa prefix
>>>     
> This prefix has been used for 10 years now, therefore it's not so simple
> to change it because it would break existing installations during upgrades.
> What is the reason for having a different default ? Which one do you
> recommend ?
the standard default one: /usr/local.

>>> - usage of a config.h headers rather than command line flags to pass C
>>> symbols for building binaries
>>>     
> Please explain why this change is needed?
That's not really needed, it's just cosmetic, and help having shorter
compilation commands:
gcc -DHAVE_CONFIG=1
instead of
gcc -DVERSION=foo -DNAME=bar -DPOSTMAP_ARGS=baz...,

Feel free to ignore (or postpone).

>>> I didn't finished the work mainly because setup is unclear. Original
>>> configure script defines a lots of different subdirectories with similar
>>> content type, whereas most software usually just define directories for:
>>> - configuration ($prefix/etc/sympa by default)
>>> - non-variable content ($prefix/share/sympa by default)
>>> - variable content ($prefix/var/lib/sympa by default)
>>> - documentation ($prefix/share/doc/sympa by default)
>>> and then install content relatively to those top-level directories.
>>>     
> We had this change in mind, ie gathering all perl modules in a lib/
> directory, all daemons in sbin/, etc.
> However I'd consider this a second time work, after all the other
> cleaning and simplification has been done.
It make senses.

>>> I didn't configured installation, nor ensured substitutions were
>>> correctly handled for those destination directories not cleary matching
>>> this standard setup (samples and user config).
>>>
>>> Also, you'll notice how performing a lot of substitutions in perl
>>> modules is cumbersome. You'd rather have a unique .pm files defining
>>> those constants (using constant pragma, or ReadOnly module), sourced by
>>> all others, so as to substitude only once.
>>>     
> It could be a good idea to get rid of all --VAR-- references in the
> code, however these are precisely data that are part of the bootstrap
> (--PERL-- refers to the path to the perl interpreter, --LIBDIR-- tells
> where to find other required perl modules, --CONFIG-- tells where the
> main configuration file stands, etc). Therefore we need these
> "bootstrap" information to be provided quite early in the process.
You need them, but you don't need to substitute them in 15 different
modules. For instance, you don't substitute VERSION in any other module
than Version.pm, and all other modules access it at runtime. What
prevent you from doing the same with all other variables ?

Attached file gives an example. I didn't tested it yet, tough, you may
have to explicitely export those constants to use them elsewhere
(bugzilla does it, for instance).

[..]
> Next week I'll manage to test the last set of patches you provided in
> your last email and I'll let you know about the results.
> If things work fine, I'll commit the changes in our SVN.
> 
> Thanks again for your help Guillaume.
You're welcome, I just try to avoid the pain of rediffing mandriva
patches for each new sympa release :)
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
# Version.pm - This module tells the current Sympa version
# RCS Identication ; $Revision: 919 $ ; $Date: 2001-11-30 11:39:10 +0100 
(ven, 30 nov 2001) $ 
#
# Sympa - SYsteme de Multi-Postage Automatique
# Copyright (c) 1997, 1998, 1999, 2000, 2001 Comite Reseau des Universites
# Copyright (c) 1997,1998, 1999 Institut Pasteur & Christophe Wolfhugel
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

package Constants;

use stricts;
use warnings;

use constant VERSION => '@VERSION@';
use constant USER    => '@USER@';
use constant GROUP   => '@GROUP@';

use constant CONFIG    => '@pkgsysconfdir@/sympa.conf';
use constant WWSCONFIG => '@pkgsysconfdir@/wwsympa.conf';

use constant BINDIR         => '@bindir@';
use constant SBINDIR        => '@sbindir@';
use constant DATADIR        => '@datadir@';
use constant PKGDATADIR     => '@pkgdatadir@';
use constant PKGSYSCONFDIR  => '@pkgsysconfdir@';
use constant LOCALESTATEDIR => '@localstatedir@';

1;