On November 10, 2002 02:40 pm, Marcus Meissner wrote:
Do not link against -lcups directly, but dynamically load it if present. (just like freetype etc.)
[...]
+#ifdef HAVE_CUPS
/* dynamically load CUPS if not yet loaded */if (!cupshandle) {cupshandle = wine_dlopen(CUPS_SONAME, RTLD_NOW, NULL, 0);if (!cupshandle) cupshandle = (void*)-1;}+#endif
Well, if we do this dynamically, why have this HAVE_CUPS check which is a compile time check? IMO we should just include a copy of the CUPS headers that we need, and drop the compile time check altogether. In fact, this check is misleading, as it suggests that we've verified some sort of compatibility with CUPS which we haven't. We _assume_ that a certain API is available at runtime, so why pretend we use something that's on the machine we compile on?
Le dim 10/11/2002 à 23:18, Dimitrie O. Paun a écrit :
On November 10, 2002 02:40 pm, Marcus Meissner wrote:
Do not link against -lcups directly, but dynamically load it if present. (just like freetype etc.)[...]
+#ifdef HAVE_CUPS
/* dynamically load CUPS if not yet loaded */if (!cupshandle) {cupshandle = wine_dlopen(CUPS_SONAME, RTLD_NOW, NULL, 0);if (!cupshandle) cupshandle = (void*)-1;}+#endif
Well, if we do this dynamically, why have this HAVE_CUPS check which is a compile time check? IMO we should just include a copy of the CUPS headers that we need, and drop the compile time check altogether. In fact, this check is misleading, as it suggests that we've verified some sort of compatibility with CUPS which we haven't. We _assume_ that a certain API is available at runtime, so why pretend we use something that's on the machine we compile on?
I don't think including foreign headers is the way to go. Better pressure packagers to have CUPS-devel installed when they compile. For self-compilation, if CUPS is not installed at compile-time, it won't be there at runtime (except if installed since then, or if CUPS-devel is not installed).
Foreign headers mean you must track new versions, etc. It doesn't seem to be the right thing to do.
Vincent
On Sun, Nov 10, 2002 at 11:18:27PM -0500, Dimitrie O. Paun wrote:
On November 10, 2002 02:40 pm, Marcus Meissner wrote:
Do not link against -lcups directly, but dynamically load it if present. (just like freetype etc.)[...]
+#ifdef HAVE_CUPS
/* dynamically load CUPS if not yet loaded */if (!cupshandle) {cupshandle = wine_dlopen(CUPS_SONAME, RTLD_NOW, NULL, 0);if (!cupshandle) cupshandle = (void*)-1;}+#endif
Well, if we do this dynamically, why have this HAVE_CUPS check which is a compile time check? IMO we should just include a copy of the CUPS headers that we need, and drop the compile time check altogether.
Actually we would just need 4 lines of function prototypes with char*, char** and int* arguments, no structures are passed.
In fact, this check is misleading, as it suggests that we've verified some sort of compatibility with CUPS which we haven't.
But we did check against at least one set of function prototypes.
We _assume_ that a certain API is available at runtime, so why pretend we use something that's on the machine we compile on?
It is the same for freetype.
I can do it the other way easily. I'll send a new patch later this day.
Ciao, Marcus
It is the same for freetype.
I can do it the other way easily. I'll send a new patch later this day.
Ciao, Marcus
Couldn't this be done for all dlls thare loaded inconditionnally by another dlls ? For example comdlg32 loads winspool.drv, even if you don't want to print anything. I loaded for example the installation of ie6 and it wanted winspool.drv, which has no sense at all.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Mon, Nov 11, 2002 at 02:26:31PM +0100, Sylvain Petreolle wrote:
It is the same for freetype.
I can do it the other way easily. I'll send a new patch later this day.
Ciao, Marcus
Couldn't this be done for all dlls thare loaded inconditionnally by another dlls ? For example comdlg32 loads winspool.drv, even if you don't want to print anything.
You could use this patch:
Index: dlls/commdlg/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/commdlg/Makefile.in,v retrieving revision 1.24 diff -u -u -r1.24 Makefile.in --- dlls/commdlg/Makefile.in 18 Oct 2002 23:46:29 -0000 1.24 +++ dlls/commdlg/Makefile.in 11 Nov 2002 20:24:39 -0000 @@ -4,7 +4,8 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = comdlg32.dll -IMPORTS = shell32 shlwapi comctl32 winspool.drv user32 gdi32 kernel32 +IMPORTS = shell32 shlwapi comctl32 user32 gdi32 kernel32 +DELAYIMPORTS = winspool.drv ALTNAMES = commdlg.dll EXTRALIBS = $(LIBUUID)
Ciao, Marcus
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, if we do this dynamically, why have this HAVE_CUPS check which is a compile time check? IMO we should just include a copy of the CUPS headers that we need, and drop the compile time check altogether. In fact, this check is misleading, as it suggests that we've verified some sort of compatibility with CUPS which we haven't. We _assume_ that a certain API is available at runtime, so why pretend we use something that's on the machine we compile on?
I think the check is just fine. If you don't have the headers you can't build CUPS support in, no matter what will be present at runtime. The assumption is that the library that you will (maybe) find at runtime is compatible with the headers you have built against; this is much better than shipping our own version of the headers and assuming all platforms are using a compatible library.
-
Alexandre Julliard -
Dimitrie O. Paun -
Marcus Meissner -
Sylvain Petreolle -
Vincent Béron