[tlbuild] dvibook failure on Cygwin

[Peter Breitenlohner]

On Tue, 28 Feb 2012, Ken Brown wrote:

>>> --- c-unistd.h.orig 2012-02-21 18:56:49.000000000 -0500
>>> +++ c-unistd.h 2012-02-27 07:58:51.290463800 -0500
>>> @@ -24,6 +24,9 @@
>>> #include <kpathsea/systypes.h>
>>> 
>>> #if HAVE_UNISTD_H
>>> +#ifdef __CYGWIN__
>>> +#include <kpathsea/getopt.h>
>>> +#endif
>>> #include <unistd.h>
>>> #endif
>>

> I think this change has to be reverted; it breaks compilation of gsftopk:

Hi Karl and Ken,

for the moment that seems to be necessary, but I'd prefer a better solution.

In particular, declaring optarg once with dllimport and once without may
cause problems

================

I have looked at four different systems with <unistd.h> and <getopt.h>: GNU
C library (i.e., Linux and Co), Cygwin, MinGW, and Mac Os X.

In all cases '#include <unistd.h>' declares getopt() but neither
getopt_long() nor 'struct option', whereas a subsequent or independent
'#include <getopt.h>' makes sure all of them are declared.

Mac Os X declares getopt() directly in unistd.h, whereas getopt.h includes
unistd.h and declares the rest.

For the other three unistd.h includes getopt.h with a special #define such
that only getopt() is declared.

================

Ideally c-unistd.h could do something similar for Cygwin:
(1) #include <kpathsea/getopt.h> in such a way that getopt_long() and
'struct option' are not declared.
(2) #include <unistd.h> in such a way that the inclusion of <getopt.h> is
skipped.
(3) Make sure that later direct inclusion of <kpathsea/getopt.h> will
declare getopt_long() and 'struct option'.

Alternatively (and somewhat less ideal) we could use the fact that in the TL
tree whoever uses getopt() always includes <kpathsea/getopt.h> and doesn't
depend on getopt() being declared via <unistd.h>:
   #if HAVE_UNISTD_H
   #if defined(__CYGWIN__) && !defined(__GETOPT_H__)
   #define __GETOPT_H__
   #include <unistd.h>
   #undef __GETOPT_H__
   #else
   #include <unistd.h>
   #endif
   #endif

What do you think?

Regards
Peter