On Tue, Mar 17, 2009 at 01:14:33AM +0100, Bruno Haible wrote:
> Colin Watson wrote:
> > I would find it more elegant to install all the files separately and
> > have a defined ordering between them
>
> It may work for you. For the general developer, I think it opens too
> many pitfalls (missing -I
Colin Watson wrote:
> I would find it more elegant to install all the files separately and
> have a defined ordering between them
It may work for you. For the general developer, I think it opens too
many pitfalls (missing -I options, confusion about which file is used,
possibly empty directories a
Eric Blake wrote:
> Maybe the solution is to expand automake's list of valid serial lines.
> True, it won't help until after the next Automake release, but if there
> are enough files in the wild that use '# file.m4 serial n', it seems like
> we should make it a valid format rather than forcing all
Hello,
* Eric Blake wrote on Mon, Mar 16, 2009 at 03:24:07PM CET:
> According to Colin Watson on 3/16/2009 8:04 AM:
> > Beyond the gettext compatibility issue, there are many files in gnulib
> > that have serial lines in a format not recognised by aclocal that have
> > nothing to do with gettext.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-automake]
According to Colin Watson on 3/16/2009 8:04 AM:
> On Mon, Mar 16, 2009 at 01:13:52PM +0100, Bruno Haible wrote:
>> Hello Colin,
>>
>>> I'm using both gettext and gnulib. In order to avoid confusing file
>>> conflicts, I tell gett
On Mon, Mar 16, 2009 at 01:13:52PM +0100, Bruno Haible wrote:
> Hello Colin,
>
> > I'm using both gettext and gnulib. In order to avoid confusing file
> > conflicts, I tell gettext to install into m4/ and gnulib to install into
> > gnulib/m4/, and rely on aclocal's documented serial number handlin
Hello Colin,
> I'm using both gettext and gnulib. In order to avoid confusing file
> conflicts, I tell gettext to install into m4/ and gnulib to install into
> gnulib/m4/, and rely on aclocal's documented serial number handling to
> sort it out. I use '-I m4 -I gnulib/m4' in ACLOCAL_AMFLAGS since
Bruno Haible writes:
> James Youngman wrote:
>> My first reaction was, why isn't libunistring===glibc
>
> glibc means to implement POSIX and be the interface to the system calls.
> The general guideline nowadays among glibc maintainers is "no new API"
> (unless it's a new system call). IIRC, when
Bruno Haible writes:
> Here is a series of two proposed patches to provide a workaround.
> Simon, is that OK to commit?
I am back from vacation now. Yes, that looks fine, but I haven't tested
it. Thanks for working on it. It will get tested by me eventually,
after the next --import run.
/Sim
I've been running into problems trying to update man-db to current
gnulib, of the following form:
configure.ac:335: warning: gl_ARGP was called before gl_LOCK_EARLY_BODY
m4/lock.m4:29: gl_LOCK_EARLY_BODY is expanded from...
m4/lock.m4:22: gl_LOCK_EARLY is expanded from...
m4/lock.m4:253: g
10 matches
Mail list logo
