Bug 23161 – Check generated binding code in SVN to better support source debugging.

• Component: Tools / Tests
• Status: RESOLVED INVALID

[Dean McNamee]

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.

[Mark Rowe (bdash)]

I am strongly opposed to having generated code checked into the repository.

[Dean McNamee]

Do you care to expand?  I think I mentioned most of the pros and cons, did I miss anything in specific?  It's a trade off, but I think there are some nice benefits.

[Mark Rowe (bdash)]

> Do you care to expand?

I'd love to.

> - It prevents some build parallelism.

On the first build where the generated files do not already exist, the build system will wait for them to be generated before moving on to compiling.  On subsequent builds this is not a problem as the files do not need to be regenerated.  This doesn't seem like a particularly large problem, and what little problem it is would be addressed if the generation was made sufficiently fast.

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

Given that our build and regression test systems are driven by perl scripts and almost all of the frequently-used scripts in WebKitTools/Scripts are written in perl, these points don't seem at all interesting.

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

This would be better addressed by fixing the code generation script to act in a more intelligent fashion.  The perl script could be modified to be invoked only once and then generate the necessary files, rather than being invoked once for each input file.  A little time could be spent optimizing the script if the performance of the script itself is really a factor.

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

Generated code is hardly an uncommon occurrence in a non-trivial software project so I would be very surprised if your tool was unable to handle it.  That said, I don't think that a limitation of a third-party tool that you happen to use warrants changing the build process for everyone.

A bigger concern is that converting an automated build step into a manual step has the effect of turning it in to voodoo.  Developers will be required to insert a manual step into their build process between "Edit" and "Compile" when they happen to have modified an IDL file.  They will have to explicitly remember to do this each and every time they modify the IDL file.  If they're not someone that frequently works on the bindings they *will* forget and be utterly confused as to why their change has not done as they would expect.

[Sam Weinig]

Closing this as INVALID.  If the issue is that generating the bindings is slow, we should speed up the bindings generator.  

[Dean McNamee]

There is also the issue for source server, which is actually quite important to us.  Should that be a separate bug?

[Mark Rowe (bdash)]

I'm not sure how the configuration of your source server is an issue for the WebKit project.

[Dean McNamee]

(In reply to comment #6)
> I'm not sure how the configuration of your source server is an issue for the
> WebKit project.
> 

Anyone building a web browser (such as Chromium) benefits greatly by having good developer tools and good integration with those tools.  The source and symbol server are not "third party" any more than windows is.  They are core and they ship with the OS.  They are core pieces of both WinDBG and Visual Studio.

We expect our developer infrastructure and tools to be just as good as other major web browsers.  For example, Mozilla hosts and supports both a symbol and source server for their developers:

https://developer.mozilla.org/en/Using_the_Mozilla_source_server
https://developer.mozilla.org/en/Using_the_Mozilla_symbol_server

I don't see why it's not in everyone's best interest (including webkit) to have the best developer experience possible.

My gut tells me if this was the same situation for Apple development tools that opinions would be much different.

[Mark Rowe (bdash)]

Again, checking in generated code to SVN is not the appropriate way to address this.  A good example of why it is not appropriate is that the binding generation scripts generate different output depending on which WebCore features you have enabled.  To make this work we'd need to rework how the bindings handle features that are optional.

It seems to me that the right approach would be to collect the generated files corresponding to a given build (which may be different than those generated by someone else that has built the exact same revision) and associate them with the build in the source server via some means.  SVN is not the appropriate way to do this.

[Mark Rowe (bdash)]

> My gut tells me if this was the same situation for Apple development tools that opinions would be much different.

This is not a constructive comment.  We at Apple *already* keep around the derived sources corresponding to a build to later assist with debugging.

[Dean McNamee]

(In reply to comment #9)
> > My gut tells me if this was the same situation for Apple development tools that opinions would be much different.
> 
> This is not a constructive comment.  We at Apple *already* keep around the
> derived sources corresponding to a build to later assist with debugging.
> 

And how do you expose them to end users / developers so that they too can source debug Safari with the generated sources?

[Mark Rowe (bdash)]

We don't.