bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

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