Re: underscores in gnulib file names

[Jim Meyering]

Ralf Wildenhues <address@hidden> 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.