My vote would be to use #if PLATFORM(XX) to wrap relevant source files, and to create new Configurations to choose which libraries to link to. I think this is the simplest while still providing the functionality we need:
-we must have the ability to link to different libraries for different builds, so that we can not link with, for example, CoreGraphics or Cairo -we do not want to have to maintain multiple project files -the #pragma comment code below looks like it gets too spaghetti-ish too quickly Cheers, Dan > > On Jan 16, 2008, at 2:19 PM, [EMAIL PROTECTED] wrote: > >> You can solve this by creating additional configurations in the same >> VS >> projects/solution. Configurations are set up to let you choose >> different >> link libraries for different targets. The different targets can >> also set >> different #defines to select CG vs Cairo, etc. >> >> Personally I don't like this so much since it is a pain to maintain >> multiple configurations, but it does solve the problem for selecting >> different libraries to link. >> >> Cheers, >> Dan >> >>> This was a non-issue for Cairo, since it was completely contained in >>> our source tree (and not externally linked against). That was less >>> than ideal though, and you still had the linking problem in the other >>> direction (with CG always being linked against). >>> >>> dave > > You can link against different libraries using the Visual Studio > "#pragma comment" feature, e.g.: > > #pragma comment(lib, "wininet.lib") > > This works, but if you want to link against debug and other variants, > you quickly end up with a mess like: > > #ifdef _DEBUG > #ifdef _UNICODE_ > #pragma comment (lib, "coollibDU.lib") > #else > #pragma comment (lib, "coollibD.lib") > #endif > #else > #ifdef _UNICODE_ > #pragma comment (lib, "coollibU.lib") > #else > #pragma comment (lib, "coollib.lib") > #endif > #endif > > I think for us to have a viable native windows port, we need to be > able to link against a pre-built Cairo libraries. > > I am just not looking forward to having to create multiple targets in > the project files, as this will involve figuring out how to pass this > along from the "build-webkit" script, etc., etc. > > But can we decide on a course of action soon? I'd like to generate a > patch that gets the win32 (native) target to build soon, but I don't > want to spend too much time on a dead-end. > > Thanks, > -Brent > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
