> This problem, the C library compatibility problem, is an
> important problem. It is currently the number one reason why
> examples in
> the 'Programming Windows 95' book don't compile.
That is not very suprising.
> I won't really tackle the issue now but I think there is a way
> to avoid the need for 'include_next'. It's not as elegant as
> 'include_next' but it does not depend on a gcc specific
> feature (I used
> this trick to solve this exact problem when porting a Unix application
> to Windows NT).
>
> * When we place a standard C header in $(WINEDIR)/include/windows,
> 'stdlib.h' for instance, and we want to include the "native" C
> header we write:
> ...
> #include "native_headers/stdlib.h"
> ...
The problem with this solution is that it ius "permanenting" the problem.
Windows, despite Microsofs's recent loss in the trail, are not going to die
anytime soon, so few will the users of WineLib be that totally abandonds
Windows for the platforms that WineLib runs on. This means that maintaining
a common codebase is critical and thus both your solation as well as mine
#include_next solution must be protected with preprocessor directives
somehow.
The problem with your solution is that as more and more code is rewritten
and adapted to Unix the more #include "native_headers/..." you will get.
Not good.
With my solution my #include "windows/..." can be eliminated one by one
as the code is rewritten and adapted and eventually they will all be gone.
In fact there are applications (the ones that currently work with WineLib)
in which they are already gone.
IHMO anybody that chooses to use your solution has in almost all cases
made a serious mistake. Most people will use GNU C anyway and with my
solution when the #include "windows/..." have finally been eliminated
non-GNU C compilers will work to.
> Then the user has to specify in his include path a directory
> which will
> contain a symbolic link called "native_headers" that points
> to where his
> C headers are.
[snip]
> * But there may be multiple standard header sets: maybe the user has
> multiple compilers (gcc+Solaris C+SunOS4 C) or multiple C libraries
> (libc5+glibc 2.0+glibc2.1).
> In that case all he has to do is create his own 'native_headers'
> directory containing his own 'native_headers' symbolic links to the C
> headers he wants. For instance:
>
> -I$(WINEDIR)/include/windows -I~/my_project/native_headers
> with
> ln -s /usr/include_glibc-2.1
> ~/my_project/native_headers/native_headers
>
> And this works even if multiple users compile code with different C
> libraries.
As you described yourself, this is another weakness with your proposal.
> As you can imagine this was a bit more primitive when I
> did it on NT
> due to the lack of symbolic links. But replace 'native_headers' by
> 'include' and put 'c:\Program Files\DevStudio\VC' is your include path
> and you basically get the same effect.
:-)
