2010/4/21 Kevin Ollivier <kev...@theolliviers.com> > Hi Marc-Antoine, > > On Apr 18, 2010, at 10:47 AM, Marc-Antoine Ruel wrote: > > 2010/4/17 Kevin Ollivier <kev...@theolliviers.com> > >> Hi Marc-Antoine, >> >> On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote: >> >> Like this? >> http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi >> >> - It is currently not JSON compliant. It's in fact a python file but that >> can be fixed: s/'/"/g and removing the extra commas *should* be >> sufficient. >> >> BTW, there is no way to make it JSON-compliant after all. Sorry for the misleading comment.
> mac, qt, gtk, wx, symbian and even some JSC files are listed. I'm 100% sure > the lists aren't complete and I'll need to fix them along the way, > especially JSC stuff which *is* a show stopper. > > .gypi files are header files. They can be imported by other .gypi or a .gyp > file. Each .gyp file will generate a .sln, .xcodeproj, Makefile or > SConstruct, depending on the selected build system. Each "target" inside a > .gyp will generate a .vcproj or .scons. > > The regex logic lives in inside "sources" entries inside a target. You can > have a list of file names, 'include' or 'exclude' with an array of regexp. > Please take a look at the very bottom of this file for an example: > http://trac.webkit.org/browser/trunk/WebCore/WebCore.gyp/WebCore.gyp > > > May I ask why it is being done this way, that is, having one really large > list of build files and using include / exclude regexs to trim the list? > i.e. why is there not a WebCoreCommon.gypi, WebCoreWinCommon.gypi, > WebCoreChromium.gypi, etc.? Are you guys using scripts to create > WebCore.gypi? > We do that for chromium, it already to support different platforms so I guess since there was already regexp done, these were simply reused. A good question, cc'ing people more knowledgeable than me. > Anyway, the fact that this file is actually Python (I had forgotten the >> format was JSON-like rather than straight JSON) makes things even better, as >> we only really need to handle export now, and not parse some import file >> list. i.e. for WebKitTools/Scripts/update-sources-list.py, >> getWebCoreFilesDict() basically becomes a very small script that execfile's >> the gypi file, then we run whatever filtering mechanism on it (waf has a >> list of ports we could use to do the filtering that I could probably move >> into WebKitTools/Scripts, if we don't have a pre-made Chromium solution >> here), and then passes the final source list along to >> generateWebCoreSourcesGTKandQT to generate the sources / includes for those >> platforms, and actually this solution should work for Android.mk and >> possibly jam too, as their syntax looks largely similar. Then we'd add some >> XML parsing code to grab the node for common file groups and update them for >> the MSVC projects, and then I think that mostly leaves XCode, which I think >> would be pretty similar in nature. >> > > For MSVC and XCode, it makes more sense to use the native gyp support since > it makes really clean projects. FYI, VS2010 is not supported for now. > > > Yes, if all MSVC and XCode projects are planning to switch over anyway, > it's probably not worth bothering with. Though if some choose not to, we > could actually re-use the chunk of Gyp code that creates the file lists and > just inject that into the project file. > Whatever works for people and is implemented. -- M-A
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev