[Webkit-unassigned] [Bug 23161] New: Check generated binding code in SVN.

[bugzilla-daemon at webkit.org]

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

           Summary: Check generated binding code in SVN.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: deanm at chromium.org


Currently, the build systems call the IDL compiler, perl code which will read
in IDL files and generate .cpp and .h files.  There are currently a few big
downsides with this approach:

- It prevents some build parallelism.

- It forces the build to have unixy tools (perl and required perl modules). 
There are probably other build steps that require these anyway, but the less
external dependencies to build, the better.

- There is possible variance between systems, depending on perl versions,
operating system, line endings, blah blah.

- Specifically on Windows, this above process is very slow (minutes).  Part of
it is cygwin and Windows process creation overhead, part of it is how the perl
is written, etc.  But the end effect is a really slow build step.

- It makes it hard to review binding code generator changes, because i can be
hard to tell the effect from a change in the perl code to the output of the .h
and .cpp files.

- A big one for me, you cannot use the integrated Microsoft source server,
since it pulls source code directly from source control.  If the bindings are
not checked in, there is no way to source debug them.  We use the symbol /
source debugging a lot when working from crash dumps, and it's really great to
be able to load up a crash dump and see the source line.

The solution of course would be to check in the generated binding code.  This
means there would be a manual step to generate .cpp and .h files.  If anyone
made changes to the code generator or IDL files (which isn't that frequent from
my experience), you would run a script that would regenerate the .cpp and .h
files, and then you would check in.  This means patches would actually be to
the .cpp and .h files, so you could see how the change affected the actual
source that will be compiled.

I think overall this is the best solution, although there is obvious a bit of
downside having to do a few steps manually.  I will probably try to implement
this for Chromium, but it makes sense to have everyone doing the same thing.


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