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
