[webkit-dev] Pulling together on WebKit Mobile

[Brent Fulgham]

On Jan 16, 2008, at 2:19 PM, zucker at wake3.com 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