Bug 106989 - Get WebKit projects compiling in VS2010 (32 bit)
Summary: Get WebKit projects compiling in VS2010 (32 bit)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 106988
Blocks: 106949 107034 107037
  Show dependency treegraph
 
Reported: 2013-01-16 01:31 PST by Roger Fong
Modified: 2013-02-08 11:44 PST (History)
4 users (show)

See Also:


Attachments
WebKit projects! (238.90 KB, patch)
2013-02-01 18:24 PST, Roger Fong
no flags Details | Formatted Diff | Diff
WebKit Projects! v2 (218.53 KB, patch)
2013-02-05 12:48 PST, Roger Fong
bfulgham: review+
bfulgham: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Fong 2013-01-16 01:31:34 PST
This include WebKitLib (which I'll probably rename to just WebKit), WebKitExportGenerator, WebKitGUID and Interfaces (which should probably be renamed into something like WebKitInterfaces).
Comment 1 Radar WebKit Bug Importer 2013-01-16 01:31:48 PST
<rdar://problem/13022852>
Comment 2 Roger Fong 2013-01-21 18:50:15 PST
minus WebKitGUID.

This project does literally nothing. 
No build scripts, no files in it, no output.
Last time it was modified was years ago.

Not going to bother removing it from the 2005 solution since we won't be using it soon anyways.
Comment 3 Brent Fulgham 2013-01-28 15:44:32 PST
(In reply to comment #2)
> minus WebKitGUID.
> 
> This project does literally nothing. 

It creates the WebKitGUID.lib, which can be linked to client programs to provide the GUIDs you need to instantiate WebKit objects.

Are you sure it's not needed?  I thought several of the test programs (and my own projects) use this library so they don't have to embed a WebKit.tlb file.

> No build scripts, no files in it, no output.

It produces $(WebKitBuildDir)\$(Configuration)\lib\WebKitGuid.lib.

> Last time it was modified was years ago.

The project doesn't need to do much, just compile the WebKit_i.c file so we can get access to the GUID symbols.
Comment 4 Roger Fong 2013-01-28 16:20:28 PST
Yeah, didn't realize that WebKit_i.c was a derived source.
Comment 5 Roger Fong 2013-01-28 16:26:16 PST
Hmm I wonder if it makes sense to combine WebKitGUID and WebKitExportGenerator into a WebKitGenerated project though. That would be nice.
Comment 6 Roger Fong 2013-01-28 16:33:22 PST
(In reply to comment #5)
> Hmm I wonder if it makes sense to combine WebKitGUID and WebKitExportGenerator into a WebKitGenerated project though. That would be nice.

Just kidding, guess we can't. One outputs a lib and one outputs an exe
Comment 7 Roger Fong 2013-01-28 18:07:17 PST
Is there a reason why the export generator works by creating an executable that prints the exports file? Why can't the script just directly print the exports file. That way I can combine WebKitGUID with the exports project.

Also we won't be able to merge a JavaScriptCoreGenerated project with a JavaScriptCoreExportGenerator if we stick with the way things are.
Comment 8 Roger Fong 2013-01-28 18:09:14 PST
Oh, I get it, preprocessor definitions. The definitions are also set as Macros though, I wonder if we can just feed those into the script directly.
Comment 9 Roger Fong 2013-01-28 18:15:33 PST
You're right Roger, that does sound gross, messy and unnecessary and we should just have a separate exports generator project for Webkit and JSC.
Comment 10 Roger Fong 2013-01-30 19:03:06 PST
> It creates the WebKitGUID.lib, which can be linked to client programs to provide the GUIDs you need to instantiate WebKit objects.

Hey Brent, do you know how this hooks in with WebKit.

I'm having trouble importing the symbols defined in WebKit_i.c.

I thought that what I had to do was import the lib file into the WebKit project but it seems that this is not the case (also the 2005 solution doesn't do this).

Including WebKit_i.c directly of course works and everything compiles wonderfully, but I'd rather not do that. Is there something I'm supposed to do with the tlb?
Thanks
Comment 11 Roger Fong 2013-02-01 18:24:36 PST
Created attachment 186199 [details]
WebKit projects!
Comment 12 Roger Fong 2013-02-01 18:25:41 PST
Relies on some changes I'm making to the WebKitLibraries folder which I'll commit soon as well.
Comment 13 Roger Fong 2013-02-04 18:15:47 PST
It would appear that the WebKitExportGenerator does not work in release mode.
Oddly everything still compiles. I guess the effect isn't seen until a project that needs to import the symbols comes along.

When I run the WebKitExportGenerator.exe it just crashes saying some dll's are missing (in particular MSVCR80.dll, shouldn't be searching for that anyways...wrong version. This leads to the actual exports file being completely empty.

Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.
Comment 14 Roger Fong 2013-02-04 18:50:42 PST
 
> Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.

Ignore side note: Fixed it. Now we have the same problem with MSVCR80 in both export generators.
Comment 15 Roger Fong 2013-02-04 19:33:54 PST
After doing some research it looks like this problem will arise if you have dll's that are compiled with VS2005 which I undoubtedly have. (A lot of the dll's that come in the WebKitSupportLibrary). 

I believe if I want this to work I have to install VS2005 and I'll get all the dll's/lib's I need with it. However I'd rather not have any dependence on old stuff. Ideally, these libs are recompiled in VS2010. Maybe they already are somewhere?

This problem will prevent me from developing in release mode. Debug mode seems to be fine however, I'm not sure why, but it seems to automatically link against MSVCR100. In fact, the dependency walker shows that the debug executable has no dependency on pthreadsVC2.dll and the like at all. I probably don't understand something about how debug mode works.
Comment 16 Brent Fulgham 2013-02-04 20:15:45 PST
(In reply to comment #15)
> After doing some research it looks like this problem will arise if you have dll's that are compiled with VS2005 which I undoubtedly have. (A lot of the dll's that come in the WebKitSupportLibrary). 
> 
> I believe if I want this to work I have to install VS2005 and I'll get all the dll's/lib's I need with it. However I'd rather not have any dependence on old stuff. Ideally, these libs are recompiled in VS2010. Maybe they already are somewhere?
> 
> This problem will prevent me from developing in release mode. Debug mode seems to be fine however, I'm not sure why, but it seems to automatically link against MSVCR100. In fact, the dependency walker shows that the debug executable has no dependency on pthreadsVC2.dll and the like at all. I probably don't understand something about how debug mode works.

Is this a problem caused by linking against two different runtime libraries (the VS2005 and VS2010 versions?)

You can probably get around installing VS2005 by just downloading the "Visual Studio Redistributable Libraries" installer.  These come with VS2005, but I believe Microsoft provides a separate set of downloads for them as well.  These will make sure the proper stuff is available in your Windows partition.
Comment 17 Brent Fulgham 2013-02-04 20:17:15 PST
(In reply to comment #13)
> It would appear that the WebKitExportGenerator does not work in release mode.
> Oddly everything still compiles. I guess the effect isn't seen until a project that needs to import the symbols comes along.
> 
> When I run the WebKitExportGenerator.exe it just crashes saying some dll's are missing (in particular MSVCR80.dll, shouldn't be searching for that anyways...wrong version. This leads to the actual exports file being completely empty.
> 
> Side Note: the same thing also happens when I tried to use my JavaScriptExportGenerator except it complained that pthreadVC2.dll was missing (although it seems to be there). The build actually does fail there though because jsc tries to import the symbols.

This sounds like the manifest file for the export generator is referencing a DLL you don't have.  Maybe CoreFoundation or something was built with VS2005 version X, and you don't happen to have the runtime libraries for Version X on your system.  This is called DLL HELL.
Comment 18 Roger Fong 2013-02-05 12:48:27 PST
Created attachment 186679 [details]
WebKit Projects! v2
Comment 19 Brent Fulgham 2013-02-05 13:12:38 PST
Comment on attachment 186679 [details]
WebKit Projects! v2

View in context: https://bugs.webkit.org/attachment.cgi?id=186679&action=review

Looks good.  I propose we (you!) land it so we can use it as a base for finalizing things.  It *might* be nice to use 'svn copy' to create some of these files that are duplicates of the things in WebKit.vcproj, just so the SVN history will show where they came from.  You might check with Jon or somebody to see if that's important to them.

I don't think this patch will land automatically, since it is not prefixed by the WebKit/Source/WebKit path, so you'll need to land it manually.

> WebKit.vcxproj/Interfaces/FixMIDLHeaders.pl:1
> +#! /usr/bin/perl -w

If this is a duplicate of the one in WebKit.vcproj, you might want to use a 'svn cp' command so that we see the history of the file (as it is 'moved' from the VS2005 location to this new location).

> WebKit.vcxproj/WebKit/WebKitCommon.props:11
> +      <PreprocessorDefinitions Condition="'$(Platform)'=='x64'">WIN32</PreprocessorDefinitions>

Is this right?  Or are you just placeholding until you do a true 64-bit target?
Comment 20 Roger Fong 2013-02-05 13:37:57 PST
Committed: http://trac.webkit.org/changeset/141924
Comment 21 Roger Fong 2013-02-05 13:40:56 PST
> > WebKit.vcxproj/WebKit/WebKitCommon.props:11
> > +      <PreprocessorDefinitions Condition="'$(Platform)'=='x64'">WIN32</PreprocessorDefinitions>
> 
> Is this right?  Or are you just placeholding until you do a true 64-bit target?

That's a mistake. The correct version of those conditioned preprocessor definitions are now in common.props. I'll get rid of these ones.
Comment 22 Roger Fong 2013-02-05 14:01:54 PST
> You can probably get around installing VS2005 by just downloading the "Visual Studio Redistributable Libraries" installer.  These come with VS2005, but I believe Microsoft provides a separate set of downloads for them as well.  These will make sure the proper stuff is available in your Windows partition.

Yeah, I was just hoping to use use anything VS2005 related at all.
I'm hoping that some of the runtime libraries get compiled in VS2010 soon (but until then I'll try installing the Redistributable libraries).