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 > > On Jan 16, 2008, at 4:10 PM, Adam Roben wrote: > >> On Jan 16, 2008, at 5:04 PM, David Hyatt wrote: >> >>> This is how we did it when we (briefly) had CG and Cairo compiling >>> simultaneously. The problem with it though is that we had a copy >>> of Cairo in our source tree and ended up having to hack the Cairo >>> source to put #if PLATFORM(CAIRO) around those files. If Cairo is >>> going to be brought in externally, that could be an issue. >> >> And in general, #ifdefing the contents of source files doesn't solve >> the problem of choosing which libs to link against. >> >> -Adam >> >>> On Jan 16, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote: >>> >>>> I like the idea of just wrapping those files with #if PLATFORM(CG). >>>> >>>> It's slightly messy, but it works and it simplifies managing a >>>> complex VS >>>> project file. >>>> >>>> Cheers, >>>> Dan >>>> >>>> ---------------------------- Original Message >>>> ---------------------------- >>>> Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile >>>> Date: Wed, January 16, 2008 1:54 pm >>>> -------------------------------------------------------------------------- >>>> >>>> On 16/01/2008, at 1:28 PM, Brent Fulgham wrote: >>>> >>>>> I took Dan's advice, and modified my config.h as follows: >>>>> >>>>> #if PLATFORM(WIN) >>>>> #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1 >>>>> #define WTF_USE_NPOBJECT 1 >>>>> #undef WTF_PLATFORM_CG >>>>> #define WTF_PLATFORM_CAIRO 1 >>>>> #undef WTF_USE_CFNETWORK >>>>> #define WTF_USE_WININET 1 >>>>> #undef WTF_PLATFORM_CF >>>>> #define WTF_USE_PTHREADS 0 >>>>> #endif >>>>> >>>>> <aside>We should probably come up with a new name for a 'native' >>>>> windows build, such as used by Adobe/AIR, Windows mobile, and a >>>>> true native Windows build.</aside> >>>>> >>>>> I also modified Visual Studio's environment to find the Cairo >>>>> headers and link libraries. >>>>> >>>>> I then started "build-webkit" and went and did other things for >>>>> about an hour. The build produces quite a few errors, many of >>>>> which are just CG-isms that I conditionalized away. In a few >>>>> cases, I resurrected the old Cairo backend code, in others I just >>>>> marked them as 'notImplemented()'. >>>>> >>>>> At this point, the remaining errors are due to the Visual Studio >>>>> project compiling the CG modules. I'm not sure how best to >>>>> approach this: >>>>> >>>>> 1. Create a brand new project for non-CG Windows >>>>> 2. Create new build targets in the existing solution for the non- >>>>> CG target. >>>>> 3. ? >>>> >>>> Possibly worth putting #if PLATFORM(CG) around SG paltform files, >>>> but >>>> i also can't think of a nice way to work around this -- does anyone >>>> know if you can make VS recognise some files as being for one target >>>> only? >>>> >>>> --Oliver >>>> >>>>> >>>>> >>>>> -Brent >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> [email protected] >>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <untitled-2.html>_______________________________________________ >>>> webkit-dev mailing list >>>> [email protected] >>>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
