(From the right address) I did it for WTF and JSC with kevino@. 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.n...@gmail.com>wrote: > On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger <joc...@chromium.org>wrote: > >> On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak <m...@apple.com> wrote: >> >>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke <dpra...@chromium.org> wrote: >>> >>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo <fpi...@apple.com> wrote: >>> >> Thanks for sharing this. >>> >> >>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel <e...@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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
