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

[bugzilla-daemon at webkit.org]

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





------- Comment #3 from mrowe at apple.com  2009-01-07 12:53 PDT -------
> 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.


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