[Webkit-unassigned] [Bug 177112] New: JSC Xcode build should use unified sources

[bugzilla-daemon at webkit.org]

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

            Bug ID: 177112
           Summary: JSC Xcode build should use unified sources
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: keith_miller at apple.com
                CC: lforschler at apple.com

We should also figure out how we are going to handle platform specific files. There are a couple of properties I think we like to have:

1) Adding files to one build system won't change the bundling of another build system
2) Adding source files should be relatively easy.
3) Minimize the build system changes.

1. or something very similar a hard requirement as it is important for helping to diagnose performance issues. There are several possible approaches we can take to listing unifiable sources in WebKit:

a) Build every .cpp file in all sub-directories. (requires every platform specific .cpp file has an ifdef)
b) Use a single source list file that uses C++ style macros to decide what files are to be built.
c) Use one source list file for each platform / platform independent files. (roughly matching the Platform*.cmake / CMakeLists.txt files) 
d) Have a script that runs to decide what files to include or not. (likely would need to be in the same language that bundler is in, currently ruby)
e) Only use source list files for Xcode.
f) Get CMake to provide the bundle/source list information to the Xcode build. (not sure if possible at all?)

I think there are a number of pros and cons to each option. 

a. 
  Pros:
    Developers no longer need to add files to the build list. 
  Cons:
    Source files will be added to the build regardless of whether or not they are needed.

b.
  Pros:
    People can add files based on feature defines.
  Cons:
    Tricky to make work with constraint 1. although it should be possible.
    Adds complexity the build system.
    Might cause weird issues with B&I.

c.
  Pros:
    Similar to the current build system.
    Doesn't require a lot of build system changes.
  Cons:
    ... dunno

d.
  Pros:
    Extremely flexible.
  Cons:
    Requires that everyone on WebKit needs to know the scripting language of choice.

e.
  Pros:
    Doesn't require changing the CMake build system.
  Cons:
    Likely thing will get out of sync.

f.
  Pros:
    Might make switch to a CMake only build system easier.
  Cons:
    Not clear if it's possible.
    Unknown amount of work.

My current opinion is that we should go with c. for now. Both because it should be the simplest to do and because it should provide all the robustness we need. While I like having a build system like b. it's more work to do and it's not clear that we can take advantage of it immediately. It also doesn't seem like it should be particularly hard to switch to something like b. later should we decide that's a better solution.

What do other people think?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170918/482c66da/attachment.html>