[Webkit-unassigned] [Bug 76418] New: [CMAKE] Split out cross-platform sources

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76418

           Summary: [CMAKE] Split out cross-platform sources
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: alp at nuanti.com
                CC: paroga at paroga.com, dbates at webkit.org,
                    ryuan.choi at samsung.com


I'd like to suggest a new guideline for the CMake files to encourage consolidation of build systems between ports, specifically to discourage future ports from bringing in more build systems.

The rule of thumb is as follows:

  "Source lists, include paths and generators that aren't specific to a single port should be kept somewhere they can be easily reused by new and existing ports."

In practice, this would mainly affect WebCore/PlatformEfl.cmake but there are bits of PlatformWinCE.cmake that look generally useful as well.

Where would the portable source lists go? If the feature relates to a third party library backend (Cairo, Pango, ICU, Curl, Soup, GStreamer etc.) I'd suggest Platform.cmake files in line with the existing Platform*.cmake pattern, keeping the core CMakeLists.txt clean.

As for features like the create_jit_stubs ARM generator in JavaScriptCore/PlatformWinCE.cmake, this should probably have gone in JavaScriptCore/CMakeLists.txt to begin with.

I think this gentle approach has a better chance of working than previous attempts to replace eg. the GTK+ build system with CMake wholesale.

Will roll a patch if there are no objections, but I've been out of the loop for a bit so putting this to the current maintainers.

(Bug #72238 has some related comments.)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.