> > I think that better will be to use CYGWIN_VERSION_API_MAJOR and
> > ..._MINOR. These numbers depend on changes in the library that have
> > influence for other applications.
>
> The purpose of the above guard is to include the file contents if the
> Cygwin version is less than 1.1.x (i.e. b20.1) and exclude it
> otherwise.
>
> From cygwin/version.h, we have the following:
>
> /* We used to use the DLL major/minor to track
> non-backward-compatible interface changes to the API. Now we
> use an API major/minor number for this purpose. */
>
> If I understand the semantics of CYGWIN_VERSION_API_MAJOR
> and CYGWIN_VERSION_API_MINOR correctly, then it is possibly
> (although unlikely) for different Cygwin versions to have the same
> CYGWIN_VERSION_API_MAJOR and CYGWIN_VERSION_API_MINOR values.
> Hence, this
> is why I feel that CYGWIN_VERSION_DLL_MAJOR is better suited
we could also use CYGWIN_VERSION_DLL_COMBINED ;-)
> in this case.
> Additionally, I have no idea what combination of
> CYGWIN_VERSION_API_MAJOR
> and CYGWIN_VERSION_API_MINOR corresponds to b20.1. Do you?
in cygwin/version.h from Cygwin B20.1 I have
API_MAJOR 0
API_MINOR 3
and
DLL_MAJOR 20
DLL_MINOR 1
With "DLL" we will depend on releases of the cygwin library and with
"API" on smaller incompatible changes. But there can be also changes in
the correspoding C library and its headers. So now I think that binding
to DLL version is a better solution, because the cygwin dll is packaged
with the C library.
Dan
