[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] proposal for fdl module

From: Eric Blake
Subject: Re: [bug-gnulib] proposal for fdl module
Date: Tue, 11 Jul 2006 07:09:44 -0600
User-agent: Thunderbird (Windows/20060516)

Hash: SHA1

[Adding automake]

According to Bruno Haible on 7/11/2006 5:59 AM:
> If this was doc targeted to end-users, this might make sense. But so far
> only getdate.texi is an end-user doc. All other doc in gnulib is targeted
> at programmers, and should therefore not be incorporated in the package
> that uses gnulib.

Actually, regexprops-generic.texi is also end-user doc, which CVS Head of
M4 wants to incorporate.

>> 2006-07-10  Eric Blake  <address@hidden>
>>      * gnulib-tool: Avoid space-tab.
> What's the point of this change? Also, please present unrelated patches
> in different mails, and commit them in different cvs commits. Otherwise
> it gets hard to track the history in CVS.

Sorry, I had already committed before I saw your mail.  The point was that
we might as well follow our own medicine - Makefile.maint discourages
space-tab sequences, becase emacs whitespace mode converts them to plain
tab.  Using tab-space instead makes it obvious that both characters were
intended, without having to fight editors trying to collapse them.

>>      (--doc-base): Add new option, for where .texi files should live.
> Before doing this, I think we should clarify the distinction between
> end-user and gnulib-user doc. I'm adding this to the README.
> *** README      4 Jan 2006 19:18:29 -0000       1.15
> --- README      11 Jul 2006 11:55:11 -0000
> ***************
> *** 59,64 ****
> --- 59,70 ----
>   * If the module needs configure-time checks, write an autoconf
>     macro for it in m4/<module>.m4. See m4/README for details.
>   * Write a module description modules/<module>, based on modules/TEMPLATE.
> + * If the module contributes a section to the end-user documentation,
> +   put this documentation in doc/<module>.texi and add it to the "Files"
> +   section of modules/<module>.  Most modules don't do this; they have only
> +   documentation for the programmer (= gnulib user).  Such documentation
> +   usually goes into the lib/ source files.  It may also go into doc/;
> +   but don't add it to the module description in this case.
>   * Add the module to the list in
>   You can test that a module builds correctly with:
> Also, in the patch, I would mention --doc-base before --tests-base.
> (tests-base is used only when --with-tests is specified, whereas doc-base
> is used always.)

Should I go ahead and update what I committed to make this change?

>>      * modules/fdl: New module, for grabbing fdl.texi.
> Automake is distributing COPYING and texinfo.tex. Why would you have
> fdl.texi distributed by gnulib-tool, not by automake? I would not like
> to see conflicts arise between automake and gnulib-tool.

You had the earlier proposal of making automake be smart enough to install
the latest upstream version of docs, rather than the version that was
current when automake was released (but most likely out of date at the
time that automake is used on a package).  If that is done, then I could
see making fdl.texi a responsibility of automake.  But for now, I find it
much more convenient to use gnulib, which is already an up-to-date
repository, as the source of COPYING, texinfo.tex, etc., rather than
relying on the out-of-date versions that automake would install.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]