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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to