Bug 196704 - [Meta][CMake] Refactoring CMake project to target-oriented design
Summary: [Meta][CMake] Refactoring CMake project to target-oriented design
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CMake (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 180064 196792 196655 196706 196741 196742 196904 197112 197173 198046
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-08 14:04 PDT by Don Olmstead
Modified: 2019-05-20 11:00 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Don Olmstead 2019-04-08 14:04:24 PDT
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.
Comment 1 Don Olmstead 2019-04-08 14:09:22 PDT
The idea is to have the same behavior as Apple's internal builds.
Comment 2 Konstantin Tokarev 2019-04-08 14:17:33 PDT
We aren't talking here about using actual ExternaProjects, right?
Comment 3 Don Olmstead 2019-04-08 14:20:15 PDT
(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.
Comment 4 Konstantin Tokarev 2019-04-08 14:24:39 PDT
I oppose to such change, that would unnecessarily complicate things for other ports and increase build time, especially for incremental builds
Comment 5 Konstantin Tokarev 2019-04-08 14:26:13 PDT
However Windows ports could use such set up if they wish to
Comment 6 Konstantin Tokarev 2019-04-08 14:35:04 PDT
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
Comment 7 Konstantin Tokarev 2019-04-08 14:39:27 PDT
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
Comment 8 Don Olmstead 2019-04-08 14:43:30 PDT
(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.
Comment 9 Konstantin Tokarev 2019-04-08 14:49:58 PDT
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
Comment 10 Don Olmstead 2019-04-08 14:51:51 PDT
(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.
Comment 11 Konstantin Tokarev 2019-04-08 14:54:26 PDT
Thanks!