Bug 196704 – [Meta][CMake] Refactoring CMake project to target-oriented design

• Status: NEW
• Component: CMake

[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.

[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!