196704 2019-04-08 14:04:24 -0700 [Meta][CMake] Refactoring CMake project to target-oriented design 2023-12-27 22:25:48 -0800 1 1 1 Unclassified WebKit CMake WebKit Nightly Build Unspecified Unspecified NEW P2 Normal --- 180064 196792 196655 196706 196741 196742 196904 197112 197173 198046 1 don.olmstead webkit-unassigned achristensen annulen fujii mcatanzaro rjcdmt666 oldest_to_newest 1525351 0 don.olmstead 2019-04-08 14:04:24 -0700 Currently the CMake build does not mimic libraries being built in isolation. This can lead to some flakiness and potential sources of error due to how includes work within a webkit library/framework. As an example headers are all placed into ForwardingHeaders. This means that someone could include include a WebCore header from inside JavaScriptCore. Same goes for the DerviedSources which all output to the same root. Each library/framework should be built similar to an external project within CMake. 1525353 1 don.olmstead 2019-04-08 14:09:22 -0700 The idea is to have the same behavior as Apple's internal builds. 1525359 2 annulen 2019-04-08 14:17:33 -0700 We aren't talking here about using actual ExternaProjects, right? 1525361 3 don.olmstead 2019-04-08 14:20:15 -0700 (In reply to Konstantin Tokarev from comment #2) > We aren't talking here about using actual ExternaProjects, right? Not yet but this would be an intermediary step towards that. Once its done and tested then we can see if Apple would be willing to give that a go so we can have one build system to rule them all. 1525363 4 annulen 2019-04-08 14:24:39 -0700 I oppose to such change, that would unnecessarily complicate things for other ports and increase build time, especially for incremental builds 1525364 5 annulen 2019-04-08 14:26:13 -0700 However Windows ports could use such set up if they wish to 1525374 6 annulen 2019-04-08 14:35:04 -0700 IDE integration would also suffer from such change, now I can open one root project for everything, and with such change I would nee to open several projects and jump between them 1525378 7 annulen 2019-04-08 14:39:27 -0700 What we actually want to achieve here is to prevent things from breaking because of different and undeterministic order of include directories. This goal is entirely feasible to achieve without breaking of integral cmake project into pieces 1525381 8 don.olmstead 2019-04-08 14:43:30 -0700 (In reply to Konstantin Tokarev from comment #7) > What we actually want to achieve here is to prevent things from breaking > because of different and undeterministic order of include directories. This > goal is entirely feasible to achieve without breaking of integral cmake > project into pieces Sorry I don't think I was clear enough for you here. This work is about cleaning up the CMake code so that includes function properly and prevent any misuse that would lead to losing deterministic builds. Do I think we should move to external project at this time? No. If Apple were willing to switch completely to CMake and because of how they build we needed to use external projects then yes I would be in favor of that. This work would complement such a change but it is not my intention to move to external project at this time. 1525392 9 annulen 2019-04-08 14:49:58 -0700 OK, this is fine with me. Sorry for misunderstanding your intentions. I think it may be useful to rename this meta-issue into something like "Refactoring CMake project to target-oriented design" to avoid misunderstanding 1525396 10 don.olmstead 2019-04-08 14:51:51 -0700 (In reply to Konstantin Tokarev from comment #9) > OK, this is fine with me. Sorry for misunderstanding your intentions. I > think it may be useful to rename this meta-issue into something like > "Refactoring CMake project to target-oriented design" to avoid > misunderstanding Changed. 1525401 11 annulen 2019-04-08 14:54:26 -0700 Thanks!