--- Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Steven Edwards <[EMAIL PROTECTED]> writes: > > > It could have just slipped through although I can think of a good > > reason not to apply it now. If would be nice to have the option to > use > > either the mingw import libs or WINEs. Our patch does hide the UUID > > problems that exist in w32api shell32.a. > > That was my thinking, yes; the Wine programs are already tested > against the Wine libraries when building on Unix, so building with a > different config on Windows lets us find more problems. But if you > really need the patch I can put it in, it's just that it removes some > flexibility.
I would agree but for the cygwin port we really dont want to use the w32api package. > > The proper solution may be to have a configure switch like > > --use-native-sdk. > > With the current setup, the native libs will be used by default, and > you can do "make programs LDFLAGS=-Lpath_to_wine_dlls" to use the > Wine > libraries. So both options are easily available. My command line is already quite long when building to test the w32api headers. If you will accept a patch I will implement a option --use-mingw-sdk that does the following. --disable-win16 CFLAGS="-D_WIN32_IE=0x0501 -D_WIN32_WINNT=0x0501 -DWINVER=0x0501 -I/mingw/include" LDFLAGS=-L/mingw/lib Then by default on a Mingw or Cygwin build we can build all of the programs with out issue and I and anyone else can still test mingw and the w32api by using the optional switch. If you will let me attempt to implement this option then please commit the programs patch. Thanks Steven __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
