Mitch Capper wrote: > > In Gnulib, we use > > #if defined _WIN32 && !defined __CYGWIN__ > > If I understand correctly anywhere I am using _WIN32 I should update it to > this dual check as cygwin may have this _WIN32 definition but it should be > treated not as _WIN32.
Yes. > > Yes, that's an adaptation that needs be made in the packages: When the > > package requests a polyfill for function XY (and this polyfill is always > > available), tests of HAVE_XY should be simplified to 1. Developers like > > this, because it makes their code easier. > > I don't think you are saying this should automatically happen (similar to > in GNULIB where most of the preprocessor directives are replaced at > configure time with 1s and 0s). I assume more so that they should manually > be removing the HAVE_XY test once they include the gnulib module? Not automatically. Manually is what I meant. > Another example, take GNU make. It has checks for HAVE_DIRENT_H in the > code, but after including the proper gnulib modules there is essentially > working directory enumeration code on Windows. It would seem odd to just > remove all HAVE_DIRENT_H checks That is not odd. That it's how Gnulib is meant to be used: Once the package has imported the 'dirent-h' module, it should be removing all HAVE_DIRENT_H conditionals. The maintainer will be happy about it, because the fewer ifdefs, the less thinking about non-GNU platforms the developer has to do. > There > are situations though that the polyfill won't work on some platforms. I > guess my question is how would I best alter this code to account for where > there _may_ be a polyfill. This even extends to things like some gnulib > modules. In the symlinkat from gnulib it only checks HAVE_SYMLINK ( > https://github.com/coreutils/gnulib/blob/master/lib/symlinkat.c#L50 ), and > fails to provide a working solution without. With the symlink fixes I > changed to make sure REPLACE_SYMLINK was defined and then to make sure both > HAVE_SYMLINK and REPLACE_SYMLINK are false before the fail function. The cases where the polyfill does not produce a working implementation need to be looked at on a case-by-case basis. Sometimes relying on the polyfill will be sufficient, sometimes we need to test for the presence of a specific gnulib module (via #if GNULIB_<module_name_uppercased>). Bruno
