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 rules,
> then ..h (or any suffix with more than one dot) won't work well
> with it.
Hi Ralf,
I don't buy the typo-gone-mad objection :-), though the latter
is a good point. Note that currently, the only rules I know of
are emitted by gnulib-tool and like this:
stdint.h: stdint_.h
stdio.h: stdio_.h
and those would work just fine, if changed to use ..h.
So maybe that's not a show-stopper.
Here are the choices for how to find a suffix different from "_.h",
indicating that a file is a template:
use ..h: con: can't use portable implicit Makefile rules
use -.h: con: the dichotomy with the four existing *--.h files:
they are not templates. IMHO that's not a big deal. Just don't
depend on their .h names in Makefiles. And elsewhere, it's
easy to match with *[^-]-.h rather than *-.h.
use -e.h: con: longer; and what does "e" stand for again? :-)
I keep reading it as exception handler.
use .eh: con: would have to teach editor that this suffix indicates
a .h file, for e.g., syntax highlighting.
stick with _.h: con: RMS doesn't like _ in file names.
Hmm.. maybe he'd be ok with "_" at the end, like that.
Regarding the non-trailing "_"s in lib/, here they are:
$ ls *_?*.[ch]
__fpending.c gl_array_oset.c gl_rbtreehash_list.c
__fpending.h gl_array_oset.h gl_rbtreehash_list.h
acl_entries.c gl_avltree_list.c gl_sublist.c
fnmatch_loop.c gl_avltree_list.h gl_sublist.h
gai_strerror.c gl_avltree_oset.c iconv_open.c
getlogin_r.c gl_avltree_oset.h inet_ntop.c
getopt_int.h gl_avltreehash_list.c inet_ntop.h
gl_anyavltree_list1.h gl_avltreehash_list.h inet_pton.c
gl_anyavltree_list2.h gl_carray_list.c inet_pton.h
gl_anyhash_list1.h gl_carray_list.h mbstok_r.c
gl_anyhash_list2.h gl_linked_list.c netinet_in_.h
gl_anylinked_list1.h gl_linked_list.h pagealign_alloc.c
gl_anylinked_list2.h gl_linkedhash_list.c pagealign_alloc.h
gl_anyrbtree_list1.h gl_linkedhash_list.h regex_internal.c
gl_anyrbtree_list2.h gl_list.c regex_internal.h
gl_anytree_list1.h gl_list.h size_max.h
gl_anytree_list2.h gl_oset.c strtok_r.c
gl_anytree_oset.h gl_oset.h sys_select_.h
gl_anytreehash_list1.h gl_rbtree_list.c sys_socket_.h
gl_anytreehash_list2.h gl_rbtree_list.h sys_stat_.h
gl_array_list.c gl_rbtree_oset.c sys_time_.h
gl_array_list.h gl_rbtree_oset.h time_r.c
I'll be happy to change my things, but Bruno is the most affected,
with all of the gl_*.[ch] and iconv_* files
After such a change, gnulib clients would have to adapt by
including the new .h file name, of course.
Here are the offending names in m4/:
$ ls *_*
arpa_inet_h.m4 intmax_t.m4 signal_h.m4 sys_stat_h.m4
clock_time.m4 inttypes_h.m4 size_max.m4 sys_time_h.m4
fcntl_h.m4 locale_h.m4 ssize_t.m4 time_h.m4
float_h.m4 math_h.m4 st_dm_mode.m4 time_r.m4
getlogin_r.m4 mbstate_t.m4 stdint_h.m4 tm_gmtoff.m4
gl_list.m4 mbstok_r.m4 stdio_h.m4 uintmax_t.m4
iconv_h.m4 netinet_in_h.m4 stdlib_h.m4 unistd_h.m4
iconv_open.m4 onceonly_2_57.m4 string_h.m4 wchar_t.m4
include_next.m4 pagealign_alloc.m4 strtok_r.m4 wint_t.m4
inet_ntop.m4 search_h.m4 sys_select_h.m4
inet_pton.m4 sig_atomic_t.m4 sys_socket_h.m4
Changing these should not affect gnulib clients.
