[webkit-reviews] review requested: [Bug 179031] Add some WebKitAdditions extension points to WebCore : [Attachment 325415] Patch

[bugzilla-daemon at webkit.org]

Daniel Bates <dbates at webkit.org> has asked  for review:
Bug 179031: Add some WebKitAdditions extension points to WebCore
https://bugs.webkit.org/show_bug.cgi?id=179031

Attachment 325415: Patch

https://bugs.webkit.org/attachment.cgi?id=325415&action=review




--- Comment #2 from Daniel Bates <dbates at webkit.org> ---
Created attachment 325415

  --> https://bugs.webkit.org/attachment.cgi?id=325415&action=review

Patch

With regards to the processing of the HTML tag names .in files I debated
between teaching make_names.pl to accept multiple --tag files and having
DerivedSources.make concatenate all the .in files before generating the HTML
tag names. This patch takes the latter approach. I chose this approach because
the former would require solving how makes_names.pl would handle more than one
namespace, namespacePrefix, namespaceURI, and fallbackJSInterfaceName keys (as
each .in file could define them). Maybe it would be sufficient to error out if
all the specified files did not have the same values for these keys? Maybe
make_names.pl should have command line options to specify values for these keys
and then assume all --tag files use the same namespace? For now I opted to
avoid these questions and concatenate the existing html/HTMLTagNames.in and any
additional .in files (in that order) before passing to make_names.pl as I'm
unclear how useful and long lasting this extension point is/will be. Let me
know if it would be better to fix up makes_names.pl and ideas for solving the
concatenation order/multiple namespace issue.