Support for pkgconfig

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> Moreover, the problem is that in Windows even codecs or SANE driver, or
> what have you end up needing GUI support, registry, etc. You may think
> you don't need any of that stuff, and start copying code, and slowly but
> surely you go down a very dangerous path, and before you know it you end
> up copying most of Wine.

Even if you need some GUI support, or some registry calls, you most
likely don't want to use the Wine variant of them. You want to add
stubs to make the calls integrate with your apps; you want controls
drawn by the dll to look like your other controls, you want settings
to be stored in your app config file not in some mysterious
system.reg file, you don't want paths to contain drive letters, etc.

Even if you may end up implementing a whole bunch of Windows
functionality, IMO you will implement it in a completely different
way.

> My hope is that we can lazily initialize enough things such that it's 
> feasible to build a Winelib app even for the simplest things. But that
> requires that (1) building Winelib apps is easy, and (2) if you don't
> use expensive features, you don't pay for them.

I don't think that's feasible, at least not without a major change in
our development philosophy, which IMO would impact binary
compatibility. If you want a lightweight environment, and good Unix
integration, what you want is to write a wrapper as thin as possible,
that calls to Unix immediately. For instance an open file dialog
should resolve to a Qt or Gtk dialog. In Wine we want just the
opposite: we want high level features to use the low level features,
and call to Unix as late as possible. So the open file dialog calls
comctl32, which calls user32, which calls x11drv, which calls the
registry, which calls the server; and you end up pulling in most of
Wine for what seems to be a trivial function.

The fact is that Wine is a large, mostly self-contained environment,
and this is not going to change even if you disguise it as a normal
Unix library. And the problem if you do that is that people will
expect it to behave like any other library, and it simply won't.

Sure, it would be nice to have a set of small independent modules that
you can mix and match with your app to get just the amount of Windows
functionality that you require. But IMO that's a different project.

-- 
Alexandre Julliard
julliard at winehq.com