[Webkit-unassigned] [Bug 27551] Make it possible to build JavaScriptCore as shared library without symbol lists

[bugzilla-daemon at webkit.org]

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





--- Comment #58 from Kevin Ollivier <kevino at theolliviers.com>  2010-07-15 15:22:11 PST ---
(In reply to comment #57)
> I’ve done large patches like this before.
> 
> A good way to get a change like this landed without having to maintain a giant patch is to get agreement on the approach, put in placeholder macros that do nothing, and then get patches landed that deploy the macros in various parts of the code, with the macros not yet functioning.
> 
> Then the last patch will just be throwing the switch and turning this on. That one is hard to make work successfully, but easy to merge.

I considered that, but too late, unfortunately. If I had realized how this would turn out, I would have waited to merge JS_EXPORTDATA and JS_EXPORTED_SYMBOL, because in order to make JS_EXPORTED_SYMBOL a stub JS_EXPORTDATA needs to stay in the code. :( It can be 'undone', but I'd have to either go through and find JS_EXPORTDATA symbols one-by-one and rename them, or go back about 6 revisions of the patch and then reapply all the fixes made in those later revisions.

The big sticking point with maintenance is the need to alter the Win project files, and that is needed because we have a system set up that is copying the WTF *String.cpp files into a place where WebCore and other projects can compile them. I don't really understand the reasoning for this, but if this could be fixed independently by someone, then it would remove a lot of the issues I've been dealing with on the Win side (e.g. the patches not applying on the EWS bot, the need to undo and redo the Win project changes whenever someone changes the project files, etc.)

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