Support for pkgconfig

[Dimitrie O. Paun]

On April 14, 2003 05:27 pm, Alexandre Julliard wrote:
> Of course that depends on what the dll does. But for the common case
> of things like codecs, you don't want to drag Wine into it. Even if
> the dll is calling a bunch of API functions, you want to stub these to
> do whatever makes sense for your app; you don't want to have to
> provide a config file, DOS drives, registry files, the wineserver, the
> X11 driver, etc. etc.

Stubbing stuff out, and copy&pasting bits of Wine code may be a bit extreme.
Yes, it will give the best performance, but it's very inconvenient, and it's
very hard to do. I would hope that we can make Wine good enough that linking
with it will not require most users to go to that extent.

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.

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.

So let's see what we can do for the examples you give above:
  - provide a config file: should be merged into the registry soon
  - DOS drives, registry files: we should have good enough defaults
	to be able to startup and operate without a registry
  - X11 driver: lazy load, if apps don't access graphical stuff,
	there's no need to even initialize this bugger
  - wineserver: that's the tricky one. I'm not sure lazy initialization
	would do anything here, but in the future we may provide a
	dummy version of sorts where the Winelib user knows there is
	only one process to worry about. Maybe even start it automatically
	only if there are more than one process to worry about :)

Hey, I don't know how feasible this ideas are, but it's probably worth
it to try to make Winelib more easily useable as a library rather than
encourage people to hack some bits out of it. I think many of the changes
are beneficial to Wine in any event. That's why I think tasking out a
long time goal may be a good thing as some of the tasks may bubble out
anyway (like the configuration work around winecfg).

-- 
Dimi.