Re: Sharing ChannelDefs bw Automake & Autoconf

[Akim Demaille]

>>> "Akim" == Akim Demaille <address@hidden> writes:

 Akim> The fact that Channels is parameterized is a Good Thing, but I still
 Akim> would like to share ChannelDefs between Automake and Autoconf.  First,
 Akim> it simplifies the maintenance (which is my major point), but will also
 Akim> help us stay synch on the warning categories (this is a huge benefit
 Akim> for both autoreconf and the user).  

 > I'm not really convinced we should do this.  Maybe there are
 > bits in that file that we can share, but I'm reluctant to share
 > all of it.

 > I agree that sharing things can make our life easier, but
 > sharing too much can also make it more difficult.  Here I think
 > it would make the maintenance harder because each time we want
 > to add a new channel, it would impact the other package, and
 > especially the other package's documentation (all -W switches
 > are documented). 

This is not really an issue.  Actually, I was already considering
having ChannelDefs generate channels.texi.

 > Also things like the strictness handling and all its associated
 > channels has nothing to do in Autoconf.

But it doesn't do any harm there.

 > I don't understand the argument about autoreconf.  Automake's -W
 > switches are better set in the AUTOMAKE_OPTIONS in Makefiles, or
 > in the AM_INIT_AUTOMAKE argument in configure.ac.  I'm not sure
 > we should encourage their use on the command line,

Hm.  I've always seen AUTOMAKE_OPTIONS as a shortcut for
AUTOMAKE_AMFLAGS.  I don't see any problems with passing warnings to
automake.

 > especially from autoreconf (but even tho, autoreconf doesn't have
 > to know which of the -W Automake supports, it can just lump them in
 > the WARNINGS envvar).

That is true, but even in this case it is nice to have autoreconf
document the warnings of them all, and catch unknown warnings on the
command line.

 Akim> The default will be that maybe some messages will be less
 Akim> application specific.

 > Also it will list some unused channels in the --help output.
 >> From the user point of view I find this really confusing.  If
 >> they are not used, why list them?

Strangely enough I see the interest of the user from a different
viewpoint: I'd much prefer to have a single unified documentation even
if it documents slightly too much, rather than two close
documentations, but that require some effort from my part to remember
when/why/where there is a difference.