Bug 80749 - [meta] Update Windows-specific code and tools
Summary: [meta] Update Windows-specific code and tools
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 80751 80760
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-10 01:25 PST by Ashod Nakashian
Modified: 2012-03-10 10:35 PST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ashod Nakashian 2012-03-10 01:25:17 PST
Some Windows-specific maintenance and improvements are due. This meta bug will track the separate bugs to bringing Windows builds of WebKit up-to-date. Some of these issues are WinCairo specific but not all.

Some of the issues to be addressed (in no particular order):

* Windows IDL files should use generic pointers in their interfaces for Windows Handles.
* Windows tests and samples shouldn't depend on Safari installation in WinCairo builds.
* WinLaunch improvements to make it more usable and serve as a better working sample.
* Visual Studio projects should be updated as follows:
 - All debug projects must define _DEBUG and all non-debug ones NDEBUG (critical for some runtime libraries and checks).
 - All projects must define their target names to match the linker output name (critical for debugging).
 - All projects must have unique PDB filenames, such that WebKit.lib and WebKit.exe don't both produce WebKit.pdb (critical for debugging).
 - All projects must have their correct property sheets included in the correct order without conflicts or duplicates (in particular, for every port, all projects must include the same set of common prop sheets).

The above list will be updated as necessary and the respective bug ID will be appended.

Note: These issues will be fixed for the current mainline Visual Studio target (VS2005) and, unless there is no conflict, will not try to address VS2010 compatibility. Where there is no conflict, the most forward-compatible approach will be used.