Support for pkgconfig

[Dimitrie O. Paun]

On 13 Apr 2003, Alexandre Julliard wrote:

> It will be fairly complex, and will probably add a lot of different
> constraints, I'm not sure it would really be an improvement over
> winebuild. If you want a really transparent solution then it should
> most likely be done directly at the linker/ld.so level.

Yes, it sounds about right. Of course, the ultimate goal would be
to be able to use Wine by doing -lwine. Now, an intermediate step
toward this goal would be to allow the program to remain a Unix
app (rather than a Winelib app), and require a more complex linking
process. Which is fairly close to what winebuild is doing currently.

But we are not there. The idea with this additional step would be
to factor all this ugliness into one spot (that is, linking), so
we can drop it altogether when the required support appears in
the linker.

Thinking more about it, the current winebuild setup is very close
to this. So what's bothering me? I guess asking people to transform
their apps to a Winelib app if they want to use Winelib.

For CUI apps, there is no difference between the current winebuild
process, and what I'm proposing (a Unix app with a non-standard link).
I think (please correct me if I'm wrong).

However, for GUI apps, people need to provide the WinMain entry
point instead of main. Maybe we can export some sort of init function,
so that they can keep their main(), and simply call a wine_init().
Doing so, we maintain the appearance of a Unix app. Of course, the
limitation would be that no Wine-related funtionality can be called
before the wine_init() call. So no more static C++ initializers, etc.
Would this be doable?

-- 
Dimi.