[webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Hajime Morrita]

(From the right address)

I did it for WTF and JSC with kevino at .
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/

I did it through an automation but the tool was so slow and hacky that it
was not capable for large WebCore codebase.

Seeing that the number of exported symbol is about 2700, manual work with
regular expression will also work
if it is OK to do the work incrementally... and if you are patient enough
:-)

--
morrita



On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa <ryosuke.niwa at gmail.com>wrote:

> On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>
>> On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>>
>>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>>> >> Thanks for sharing this.
>>> >>
>>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel <eric at webkit.org> wrote:
>>> >>
>>> >> I wish we only had one build system (it were easy to add/remove/move
>>> files).
>>> >>
>>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>>> >> unhealthy sign for the project.  Adam is not the only person who has
>>> chosen
>>> >> to empty files instead of removing them.  The pain of updating 8 build
>>> >> system is so great, we jump through hoops to avoid it.  Which means
>>> it took
>>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years
>>> to kill
>>> >> WebCore/platform.
>>> >>
>>> >>
>>> >> +1
>>> >>
>>> >> This is a hard problem.  It is a problem worth solving.
>>> >>
>>> >> Do you have more thoughts on this, particularly since you know quite
>>> well
>>> >> how both Xcode and gyp work?
>>> >>
>>> >> I suspect this is one of those things that it would be hard to achieve
>>> >> consensus on since there are so many stakeholders.  But it may be
>>> fruitful
>>> >> to have a "what if" discussion about what this might look like.
>>> >>
>>> >
>>> > I think we can solve this problem if we agree that we want to. I think
>>> > we haven't in the past mostly because we couldn't reach a consensus
>>> > that it was worth solving enough to really try.
>>> >
>>> > I would love to see this fixed and would be glad to work on it. I
>>> > think we should at least pursue this far enough to fully understand
>>> > what our options are and what the costs and tradeoffs might be; does
>>> > anyone disagree, and is anyone else willing to help pitch in?
>>> >
>>> > I think there are several possible ways we could solve this. One would
>>> > be to switch to a common meta-build system. My understanding is that
>>> > Apple's internal production build processes impose certain constraints
>>> > here that I don't fully understand, but I know we've discussed the
>>> > possibility of checking in generated project files as a workaround.
>>> > Maybe there are other options as well to those constraints? I would
>>> > love to discuss this further w/ someone from Apple ...
>>>
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>>> checked in to source control.
>>> (b) The generated project invokes only tools that are part of the
>>> default Mac OS X install.
>>>
>>
>> Another desirable property would be to move to a more automatic way of
>> handling exported symbols: Currently each port that depends on this feature
>> has its own .exp file or similar. I think if we could move to something
>> that would allow for changing WebCore API without having to touch all those
>> files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win
>>
>
> morrita already did this for WTF, and it works great for us. What's
> blocking us from doing the same for WebCore?
>
> - R. Niwa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130131/0dc14f2a/attachment.html>