Re: maintainer mode

[Alexandre Duret-Lutz]

Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evil
on a stick" point of view.  I know some people find it useful
(although I don't know when).

>>> "Chadwick" == Chadwick A McHenry <address@hidden> writes:

[...]

 Chadwick> From the original thread (below) I get the impression
 Chadwick> that if automake and friends are on the users
 Chadwick> machine, and are not the same version as used by me
 Chadwick> (the developer), there could be 'trouble' due to
 Chadwick> ./configure testing for auto*. 

*Testing* for these tools will not break your build. 

Now there are three cases:

 1. The user unpacked your package, and then run ./configure and make.
    Since all the configury files (configure, Makefile.in, config.h, etc.)
    are up-to-date w.r.t. their sources (configure.ac, Makefile.am, etc.)
    there is no need to rerun any of the auto* tools.
    So you checked for those tools but whether you find them or not
    isn't important since they are not used.  This is the most
    common "user" case.

 2. The user modified configure.ac, or Makefile.am, or a sibling.  
    Obviously something needs to be regenerated to reflect these changes.
    Automake has added rules for this purpose in the Makefiles; these
    rules use the auto* tools found by configure.  If these tools
    was not found, the "missing" script prints an error message so
    the user understand he needs them.

 3. Your package is broken, it contains some files which are
    out-of-date w.r.t. their source.  The user then get "missing"
    errors when they try to build.  He reports them to you,
    and you fix your package.  (I don't think it can happen
    if you use 'make distcheck'.)

Let's see what happens when AM_MAINTAINER_MODE is used:

 1. Just the same.

 2. Running `make' after changing something doesn't update the
    dependencies.  The user has to _know_ he should
    --enable-maintainer-mode, otherwise he will wonder why his
    changes have no effect (or worse: he won't notice they
    wasn't taken into account).

 3. Although the package is broken (for instance configure
    doesn't reflect the content of configure.ac), the build will
    start anyway because the bug is *hidden*, and it may fail
    latter because of this non obvious configure/configure.ac
    mismatch.

In the common case (1.) using AM_MAINTAINER_MODE changes
nothing, in less usual cases (2., 3.) it just hides bugs when
you forget to type --enable-maintainer-mode.

(If you search the web for discussion about AM_MAINTAINER_MODE
you will find some worth-reading rants from François Pinard on
this topic, with some more philosophical points -- I'm sorry I
don't have any pointer handy.)

As far incompatibilities between different versions of these
tools are concerned, this is unrelated to AM_MAINTAINER_MODE.
If you have changed some source, you need the right tool to
rebuilt it (and obviously you want the maintainer rules too).
If however you touched nothing, you don't care about which
versions you have.
-- 
Alexandre Duret-Lutz