[webkit-dev] Pulling together on WebKit Mobile

[zucker at wake3.com]

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, zucker at wake3.com 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
>>>>> webkit-dev at lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>> <untitled-2.html>_______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>