[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] getstr(), readline()
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] getstr(), readline() |
Date: |
Tue, 7 Jan 2003 14:35:02 +0100 (CET) |
Paul Eggert wrote:
> However, it'd be better to simply change
> the names rather than try to support both the old (colliding) names
> and the new (better-chosen, noncolliding) names, as that will avoid
> confusion in the future, and it will let people use both gnulib and
> the colliding names in the same module.
>
> Also, nobody was invoking gnulib getstr directly as far as I know;
> it was purely a helper function. So it should be private anyway.
Agreed.
> How about this untested patch to simplify things accordingly? I don't
> really know how the module stuff works yet, so the modules changes are
> a bit of a guess.
The patch looks good except for one thing: In m4/getline.m4 the
added prerequisites for lib/getline.c should go into the macro
gl_PREREQ_GETLINE, not AM_FUNC_GETLINE. Of course in this case,
since it's only an AC_REQUIRE, it doesn't matter, but still I think
this separation (explained in detail in m4/README) is good because
- If getline.c is not compiled on a particular platform, it's not
necessary to check for its prerequisites.
- If another file foobar.c would #include "getline.c", it should
be sufficient to mention
AC_REQUIRE([gl_PREREQ_GETLINE])
inside gl_PREREQ_FOOBAR. We have this situation a couple of times
with strtol.c and similar files.
The patches to MODULES.txt are not be necessary any more.
Similarly, I think we should now remove lib/Makefile.am. All its
information is contained in the module descriptions, and
"gnulib-tool --create-testdir" generates a lib/Makefile.am just fine.
Bruno
- Re: [Bug-gnulib] getstr(), readline(),
Bruno Haible <=