Re: <dirent.h> on msvc

[Bruno Haible]

Hi John,

> | > this platforms lacks
> | > <dirent.h>, opendir, readdir, but we have not had a single request
> | > for supporting this in gnulib in 7 years.
> | 
> | dirent functions are actually not _that_ much used.
> 
> Sorry for jumping in late to this thread...
> 
> Octave, which attempts to be buildable with MSVC, uses dirent.h and
> the functions opendir, readdir, and closedir.  My understanding is
> that these functions are not available by default when compiling with
> MSVC.  We have some lame replacements for these functions, and I think
> Emacs also has replacements for them.  I would guess that there are
> other implementations out there as well.  But it would be much better
> if there were some replacements in gnulib.
> 
> OTOH, Octave doesn't absolutely require these functions or dirent.h,
> but we do need some (hopefully portable) way to get a list of files in
> a directory.
> 
> What's the right gnulibish way to do that,

The way to do that is that you provide a good implementation of said
functions opendir, readdir, and closedir. We don't want gratuitous
binary incompatibilities between mingw and msvc, therefore it is a good
idea to take the 'DIR' and 'struct dirent' types from the mingw header
files. Regarding the implementation of the functions, it is essential
that they be reliable and - of course - under an FSF copyright. If
you find that the mingw implementation is reliable and public domain,
you can reformat it to GNU style and submit it to us. Otherwise it's
probably better if you or some other good hacker writes one from scratch.

Together with such a module, please also provide a unit test.

The macrology (m4/dirent_h.m4 and similar) is something that follows
common gnulib idioms. If you don't understand these idioms by looking
at other .in.h files, we can do this part for you.

> and will it work on Windows systems with MSVC?

Projects that use gnulib have to overcome three hurdles when using MSVC
(as opposed to mingw):
  1) They have to have a way to execute shell scripts and execute
     Unix-style Makefiles. Not 'nmake'. Some people may use MSYS for this.
  2) They have to have a wrapper around the compiler that understands
     the common options (-o, -c, -E etc.). Some people use scripts called
     'cccl' or 'cccl2' for this.
  3) They have to make sure that the installation program for the binaries
     does NOT install any Microsoft binary-only component, because that
     would be a violation of the GPL. (I think the binaries of GNU Octave
     did that at some time.)

All these obstacles are nonexistent when projects use mingw.

Bruno