> 2) Similarly for texinfo.tex:
It would be better for packages using gnulib to get texinfo.tex from
gnulib. It's (nearly always) newer.
Of course, not all automake-using packages use gnulib. So then getting
texinfo.tex from automake is useful (I guess).
So, does automake refrain from inst
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson writes:
>> So I don't see where the conflict is.
>
> We do not yet have a conflict. But we nearly have it:
>
> 1) If fdl.texi gets distributed by automake as well, we get a conflict:
>"automake -a" and "gnulib-tool --update" would inst
Eric Blake writes:
> > 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 t
Eric Blake wrote:
> >>* gnulib-tool: Avoid space-tab.
> ...
> 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.
Thanks for explaining.
Bruno
Eric Blake <[EMAIL PROTECTED]> writes:
>>> * 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 gnul
-BEGIN PGP SIGNED MESSAGE-
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 there
