Bug 181500 – [Win] WebKitLegacy should be a dll, not a static library.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Per Arne Vollan]

Currently, WebKitLegacy is built as a static library.

[Radar WebKit Bug Importer]

<rdar://problem/36418479>

[Per Arne Vollan]

Created attachment 330981 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 330981 [details]
Patch

Clearing flags on attachment: 330981

Committed r226758: <https://trac.webkit.org/changeset/226758>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Per Arne Vollan]

Thanks for reviewing!

[Michael Catanzaro]

I was going to say:

"This isn't right, those are both the default library types for those libs now. I think this patch is a no-op, unless the Windows port is setting these types to undesired values somewhere else."

and then revert this patch.

But, is it possible that you're not running the toplevel CMakeLists.txt at all, for internal builds? That is where the default library types are defined. If so, how is that code supposed to get run? And how does OptionsWin get run instead?

[Michael Catanzaro]

Note: I removed these from OptionsWin.cmake in r226266, when I changed the default library types, because they had become redundant, and it seemed clearer to set library types only for those libraries that deviate from the WebKit project defaults on a given port.

Or so I thought. Maybe the Apple ports need to be special, if they don't run the toplevel CMakeLists.txt.

[Alex Christensen]

Only in the internal build, there is no top-level CMakeLists.txt.  There is only what is in Source/cmake and what is in the currently building directory, like what is in Source/JavaScriptCore for example.  This change did not fix anything on public bots because they use the top level CMakeLists.txt but it fixed the internal build.