Re: [Automake-NG] [PATCH] [ng] maintainer-mode: remove it altogether

[Stefano Lattarini]

On 08/09/2012 04:20 PM, Bob Friesenhahn wrote:
> On Thu, 9 Aug 2012, Stefano Lattarini wrote:
> 
>> The best explanation for this move is given by excerpts from the
>> Automake manual itself:
> 
> Complete removal of the AM_MAINTAINER_MODE macro and option are not something
> I can agree with unless there is a work-around for other common uses.  The
> assumption seems to be that this mode is only used to control if autotools
> files are automatically re-generated.  This would be a wrong assumption
> based on actual practice.  Even if automake ignores maintainer mode for its
> own purposes, it should still be supported for other purposes.
>
Then such packages should, when converting to Automake-NG, define their own
Automake conditional to disable/enable their custom maintainer-specific
rules and or subsystems.

> My package uses maintainer mode for much more than gating autotools 
> regeneration.
> It uses it to block complex operations which require that particular tools be
> installed and configured correctly on the system.  For example, I use it to 
> block
> rules for automatic generation of web pages and other documentation.  Indeed,
> even editing a C source file may cause documentation to be regenerated (as it
> does for my package).
> 
> There was nothing in the Automake manual which said that maintainer mode 
> should
> not be used for more than gating autotools regeneration and it is the standard
> way to determine if maintainer-like activities should be supported.
>
That is a limit of the manual then, which is too late to correct.  Since the
removal I'm proposing would affect only Automake-NG, I'd rather not touch
the mainline Automake manual in any way, and instead just improve the NG-NEWS
file in the Automake-NG with more examples to simplify the transition.  Care
to give some suggestion here?  Maybe a dumbed-down version of what your
packages do ...

> The package maintainer carefully crafts his system to make sure that the
> appropriate tools are available.  Output which can not be tested is
> inspected to assure that it is ok.  The end-user who builds the software
> might have older, newer, or differently-configured tools which may or
> may not produce similar output to the generated files which were included
> in the tarball.
>
That's why the files generated by maintainer tools should be distributed.
Once they are, and the distribution tarball gets not botched somehow, the
rules requiring such maintainer tools should not be executed on the use
machine anyway, independently from the presence or absence of maintainer
mode.

> It is not reasonable for the configure script to be able to completely
> validate the user's environment.  A similarly named program might produce
> significantly different output or just be a similarly named program which
> does something completely different.
>
Your arguments seems to imply I'm suggesting to stop distributing generated
files altogether ...  This is not the case!

> As an example, an OS distribution maintainer may want to patch the the
> project to fix a bug, but in the process, he might trash the project
> documentation because the available tool is configured differently or
> the wrong version.
>
Then the maintainer should provide a way to disable the automatic
rebuilding of the documentation.  Since the rules to do so are not
provided by Automake, it not Automake business to provide special
means to do so; a simple user-defined Automake conditional (say
'ENABLE_DOC_REBUILD_RULES') would suffice.

> I can attest that others on the several projects I help out on are
> bewildered by autotools and automatic maintainer rules.
>
How so?

> Anything which diminishes this bewilderment and decreases risk helps.
>
But the maintainer-mode increases the risk of having the build tree in
an inconsistent status.

Regards,
  Stefano