Bug 196704
| Summary: | [Meta][CMake] Refactoring CMake project to target-oriented design | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Don Olmstead <don.olmstead> |
| Component: | CMake | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | achristensen, annulen, Hironori.Fujii, mcatanzaro, rjcdmt666 |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 180064, 196792, 196655, 196706, 196741, 196742, 196904, 197112, 197173, 198046 | ||
| Bug Blocks: | |||
Don Olmstead
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Don Olmstead
The idea is to have the same behavior as Apple's internal builds.
Konstantin Tokarev
We aren't talking here about using actual ExternaProjects, right?
Don Olmstead
(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.
Konstantin Tokarev
I oppose to such change, that would unnecessarily complicate things for other ports and increase build time, especially for incremental builds
Konstantin Tokarev
However Windows ports could use such set up if they wish to
Konstantin Tokarev
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
Konstantin Tokarev
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
Don Olmstead
(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.
Konstantin Tokarev
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
Don Olmstead
(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.
Konstantin Tokarev
Thanks!