[webkit-dev] Build system complexity

Kevin Ollivier kevino at theolliviers.com
Fri Aug 13 09:59:10 PDT 2010


Hi Maciej,

On Aug 13, 2010, at 12:34 AM, Maciej Stachowiak wrote:

> 
> On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote:
> 
>> Are there currently any plans for simplifying the situation regarding build systems?  I haven't seen any threads for a while, which I assume means no.
>> 
>> Is there any low hanging fruit out there?  Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation.  Or reduce the process down to updating one file and then running a script that updates/generates the rest.  Currently, I cringe every time I find out I need to add a new file.
>> 
>> In addition, has anyone ever looked at simplifying the mac port's xcode project?  It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc.  Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac?
> 
> I think we should switch over to export control specified in the headers and not use .exp files any more. WebKit2.framework builds on all its target platforms with no external export control file. The hardest case for this is probably WebCore, though, and I'm not sure how practical it is to do incrementally.

Actually, this reminds me of one thing I've been meaning to ask about this regarding moving JSCore export definitions into the headers. The export symbol definitions (such as JS_EXPORTDATA, JS_EXPORT_PRIVATE, etc.) are defined multiple ways in multiple places (e.g. various project's config.h headers), and I was hoping we could move towards having some sort of WTF_EXPORT and WTF_IMPORT macros, then set macros like JS_EXPORTDATA based on them, so that we're not continually copying and pasting the same macro setting logic into each project's config.h or somewhere else. Kind of like a project-wide equivalent to JSBase.h for JSCore public API.

You can see this quite well how many places these macros are copied over to by looking at the last patch for https://bugs.webkit.org/show_bug.cgi?id=27551, but that's a pretty large patch, so a simpler case which clearly shows how we need to copy and paste these macros each time a new component needs export symbol control can be found in a patch I recently submitted here: https://bugs.webkit.org/show_bug.cgi?id=43204 

One thing that seems to make consolidating these macros into one location tricky is that WTF seems the most suitable place for it, but it is still technically a private implementation detail of JSCore, and there seems to be with some ports a great deal of effort put into isolating each project's headers and sources from the other projects. (With the Windows build particularly, I noticed a lot of copying of headers and even some implementation files from one project to another using the build directory as an intermediary.) I'd like to have some file that could be included by everything from JSCore to DumpRenderTree and, at least indirectly, by client apps (e.g. when I use those macros in wxWebKit API), without having that sort of copying set up in all the ports. Is there currently an appropriate place for such a thing to go? If not, any suggestions on the best way to approach this? Or am I missing some obvious and simple solution here? 

Thanks,

Kevin

> Regards,
> Maciej
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



More information about the webkit-dev mailing list