Bruno Haible <[EMAIL PROTECTED]> wrote:
> Committed.
>
>> 2007-09-30 Bruno Haible <[EMAIL PROTECTED]>
...
>> * modules/unistd (Files, Makefile.am): Use unistd.in.h instead of
>> unistd_.h.
I've just fixed the last one:
(thanks to Bob and his buildbot for spotting the
problem so quickly
Committed.
> 2007-09-30 Bruno Haible <[EMAIL PROTECTED]>
>
> * lib/alloca.in.h: Renamed from lib/alloca_.h.
> * lib/argz.in.h: Renamed from lib/argz_.h.
> * lib/byteswap.in.h: Renamed from lib/byteswap_.h.
> * lib/dirent.in.h: Renamed from lib/dirent_.h.
> * lib/fc
Paul Eggert wrote on 2007-09-11:
> I assume we should use the ".in.h"
> suffix instead? I can propose a patch along those lines.
That was 3 weeks ago. Since preparing this patch is purely mechanical, I
hope you don't mind if I will do it. Here is a proposed patch. (Time to
learn about "git-mv"...
Eric Blake wrote:
> After more testing, here's what I committed:
>
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=2770108
Thanks. Looks fine. Only for the indentation, I slightly prefer this style
(so that it's easier to insert new statements or swap lines or similar).
2007-09-29 Brun
Eric Blake byu.net> writes:
> >> And in the process, broke builds for platforms that lack __fpending
> >> (such as cygwin), since AC_REPLACE_FUNCS is a stickler about
> >> __fpending.c existing in that case. (I didn't notice it until now,
> >> because I had been doing incremental builds where a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jim, Bruno,
According to Jim Meyering on 9/25/2007 3:42 AM:
>> And in the process, broke builds for platforms that lack __fpending
>> (such as cygwin), since AC_REPLACE_FUNCS is a stickler about
>> __fpending.c existing in that case. (I didn't not
Eric Blake-1 <[EMAIL PROTECTED]> wrote:
>> In fact, I've just removed the underscores in __fpending.[ch]:
>>
>> 2007-09-08 Jim Meyering <[EMAIL PROTECTED]>
>>
>> Rename __fpending.c -> fpending.c and __fpending.h -> fpending.h
>> * lib/fpending.h: Rename from __fpending.h.
>
> And in th
if HAVE_STDIO_EXT_H
@@ -74,5 +75,6 @@ AC_DEFUN([gl_FUNC_FPENDING],
AC_DEFINE_UNQUOTED(PENDING_OUTPUT_N_BYTES,
$ac_cv_sys_pending_output_n_bytes,
[the number of pending output bytes on stream `fp'])
+AC_LIBOBJ([fpending])
fi
])
--
1.5.3.2
--
View this message in context:
http:
On 9/12/07, Jim Meyering <[EMAIL PROTECTED]> wrote:
> [background: there are fts functions and an fts.h in glibc,
> but there are fundamental ABI differences, so glibc cannot
> (or will not) break ABI compatibility to take advantage
> of the improvements in the gnulib version. ]
>
> So, I'm goin
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Eli Zaretskii replied with this statement:
>
> Since DOS is no longer an issue, I assume we should use the ".in.h"
> suffix instead? I can propose a patch along those lines.
Good!
You probably already know that
Paul Eggert wrote:
> Since DOS is no longer an issue, I assume we should use the ".in.h"
> suffix instead?
That's my understanding.
- It has no underscores.
- Editors see the suffix ".h" and enable syntax-coloring.
- The ".in" reminds the autoconf macro substitution.
- It is sufficiently c
Bruno Haible <[EMAIL PROTECTED]> writes:
> Eli Zaretskii replied with this statement:
Since DOS is no longer an issue, I assume we should use the ".in.h"
suffix instead? I can propose a patch along those lines.
Hi,
Eli Zaretskii replied with this statement:
> It's most probable that Emacs 23, when it is out, will not support the
> MS-DOS (a.k.a. DJGPP) build. The reason is that (a) there are too
> many changes in the Emacs CVS, even today, before the merge of the
> Unicode branch, that break the DJGPP
Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
> > - We can also use a "-in.h" suffix now. It smells the workaround (like
> > "install-sh" which is a workaround for the intended "install.sh"), but
> > it may be good enough.
>
> I prefer this solution to the "wait for DO
>> - We can also use a "-in.h" suffix now.
Fine by me.
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> - We can also use a "-in.h" suffix now. It smells the workaround (like
>> "install-sh" which is a workaround for the intended "install.sh"), but
>> it may be good enough.
>
> I prefer this solution to t
Bruno Haible <[EMAIL PROTECTED]> writes:
> - We can also use a "-in.h" suffix now. It smells the workaround (like
> "install-sh" which is a workaround for the intended "install.sh"), but
> it may be good enough.
I prefer this solution to the "wait for DOS support to die" solution.
Shou
Hi Jim,
> >> m4/group-member.m4
> >> lib/group-member.c
> >> lib/group-member.h
> >> modules/group-member
> >>
> >> ... Do you find those confusing?
> >
> > Somewhat, yes.
>
> Surely you're exaggerating -- for the sake of argument?
The confusion is not big. But here's where I would put d
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It is not confusing to me that the group_member function
>> has the following corresponding files in gnulib:
>>
>> m4/group-member.m4
>> lib/group-member.c
>> lib/group-member.h
>> modules/group-member
>>
>> ... Do you find th
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
> But still I'm glad that we have no file called '--fpending.c' :-)
In fact, I've just removed the underscores in __fpending.[ch]:
2007-09-08 Jim Meyering <[EMAIL PROTECTED]>
Rename __fpending.c -> fpending.c and __fpending.h -> fpending.h
Jim Meyering wrote:
> I could live with ".in.h".
Good, thanks.
> However, I fear that if we depend on an "ok" from the Emacs maintainers,
> then neither "..h" nor ".in.h" will fly. Currently, no file name
> in emacs contains more than one ".".
That's my fear too: The Emacs 22.1 release still ha
Jim Meyering wrote:
> It is not confusing to me that the group_member function
> has the following corresponding files in gnulib:
>
> m4/group-member.m4
> lib/group-member.c
> lib/group-member.h
> modules/group-member
>
> ... Do you find those confusing?
Somewhat, yes.
> I've made an ef
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/8/2007 7:02 AM:
> I find the "-" to be just as readable as "_", and easier to type.
> It's not hard to make the association.
I much prefer '-' over '_' in filenames, because I always enable
case-insensitive tab completio
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I prefer ..h, too. Does anyone object?
>
> I can accept "..h", but I prefer ".in.h", so as to remind the substitution of
> autoconf macros.
>
> You need to ask the Emacs maintainers whether they can accept file names with
> two dots
Hi Bruno,
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> It's not that bizarre, and it's been present in the GNU culture
>> for a very long time. "-" is easier to type than "_", since
>> the former is a single key-press and the latter usually requires two.
>> Perhaps the fact that it is not as well k
Jim Meyering wrote:
> I prefer ..h, too. Does anyone object?
I can accept "..h", but I prefer ".in.h", so as to remind the substitution of
autoconf macros.
You need to ask the Emacs maintainers whether they can accept file names with
two dots in them (DOS, VMS portability problems).
Bruno
Paul Eggert wrote:
> > How about the "..h" suffix, e.g., stdlib..h? Do we care enough
> > about 8.3 limitations to worry about that?
>
> I don't think we do nowadays, no. Might some software get confused by
> the "..h" extension? Emacs treats "..h" like ".h"; perhaps that's
> good enough.
kate
Hi Jim,
> It's not that bizarre, and it's been present in the GNU culture
> for a very long time. "-" is easier to type than "_", since
> the former is a single key-press and the latter usually requires two.
> Perhaps the fact that it is not as well known as it should be is
> the reason there are
Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hello Jim, all,
>
> * Jim Meyering wrote on Fri, Sep 07, 2007 at 09:35:14PM CEST:
>>
>> I prefer ..h, too. Does anyone object?
>
> Two reasons against it: it looks too much like a typo gone mad.
> And if you ever happen to use portable make inference ru
Hello Jim, all,
* Jim Meyering wrote on Fri, Sep 07, 2007 at 09:35:14PM CEST:
>
> I prefer ..h, too. Does anyone object?
Two reasons against it: it looks too much like a typo gone mad.
And if you ever happen to use portable make inference rules,
then ..h (or any suffix with more than one dot) w
I prefer ..h, too. Does anyone object?
I don't object myself, but since this whole thread started (as I
understand it) because rms complained, you might want to ask him too.
k
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> I admit that .eh seems a little odd, and would
>> require everyone to teach their editor about the new suffix.
>
> True; that's a pain.
>
>> How about the "..h" suffix, e.g., stdlib..h? Do we care enough
>> abou
Jim Meyering <[EMAIL PROTECTED]> writes:
> I admit that .eh seems a little odd, and would
> require everyone to teach their editor about the new suffix.
True; that's a pain.
> How about the "..h" suffix, e.g., stdlib..h? Do we care enough
> about 8.3 limitations to worry about that?
I don't th
[EMAIL PROTECTED] (Karl Berry) wrote:
> I see it's not specifically mentioned in standards.info.
> Maybe someone will add it, there.
>
> "someone" = mail bug-standards, preferably with a patch, and I will
> raise it with rms. That is, if we really want it.
Thanks.
> At least those pa
I see it's not specifically mentioned in standards.info.
Maybe someone will add it, there.
"someone" = mail bug-standards, preferably with a patch, and I will
raise it with rms. That is, if we really want it.
At least those particular cases don't bother me as much as say,
foo_bar
Eric Blake wrote:
> But editors (at least good ones, including vi, emacs, and kate) can be
> taught about new suffixes, and once taught, will treat .eh like .h.
Solving a problem for yourself is one thing; solving it for all the people
who look at the gnulib sources from outside is another.
I did
Jim Meyering <[EMAIL PROTECTED]> wrote:
> glibc is very nice software, but it is not a model
> of adherence to GNU or portability standards.
Whoops. Don't want to sound *too* inflammatory :-) Let me rephrase:
glibc doesn't bend over backwards to support losing C compilers
(or any non-gcc ones?)
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul,
>
>> RMS writes:
>>
>> > Our convention is to use dashes, not underscores.
>> > The names getopt_.h and getopt_int.h don't follow
>> > this convention.
I'm open to such a change.
I admit that .eh seems a little odd, and would
require everyone to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 9/6/2007 5:02 PM:
> Hi Paul,
>
>> * Change getopt_.h to getopt.eh, and similarly for the other files
>> whose names end in "-.h". ".eh" is short for "edit-needed header".
>
> This is awful. Text editors, xgettext, and
Hi Paul,
> RMS writes:
>
> > Our convention is to use dashes, not underscores.
> > The names getopt_.h and getopt_int.h don't follow
> > this convention.
Where does this "convention" come from? It's the first time I hear about
such a bizarre requirement.
POSIX does not specify the existence of
RMS writes:
> Our convention is to use dashes, not underscores.
> The names getopt_.h and getopt_int.h don't follow
> this convention.
> In the long term, would you please change them?
Here's one way to satisfy this request:
* Change getopt_int.h to getopt-int.h.
* Change getopt_.h to getopt.e
41 matches
Mail list logo
