On Mon, Jan 17, 2011 at 4:28 AM, Patrick Gansterer <[email protected]> wrote: > Adam Barth: >>> Otherwise we need to keep the files in the root directory. :-( >> >> I'm not sure I understand the connection. For example, >> cmakeconfig.h.cmake seems to be entirely concerned with WebCore >> concepts (essentially which features are enabled): >> >> http://trac.webkit.org/browser/trunk/cmakeconfig.h.cmake >> >> Surely the launchers don't need to peer into these internal details of >> WebCore. > > Ok, cmakeconfig.h.cmake can be moved, but i see the problem with the > following lines: > http://trac.webkit.org/browser/trunk/CMakeLists.txt?rev=75908#L15 > http://trac.webkit.org/browser/trunk/WebKit.pro?rev=75908#L13 > > The launchers only need the WebKit-API, but we have _one_ buildsystem, which > builds _all_ targets (including launcher) and needs to know about them.
It sounds like there are couple of approaches that could work here: 1) In the Mac and Win build system, the launcher projects are independent projects, just like you would create if you were a consumer of WebKit outside of the WebKit source tree. The wrapper script, build-webkit, knows how to kick off the various builds so you can build everything easily. 2) Another approach is to have the "main" build system for WebKit refer to all the various other targets, even if they're outside of the Source directory. For example, that's how WebKit.gyp works: http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/WebKit.gyp My preference is for approach (1) because it more cleanly separates the source code that goes into the WebKit target from all the peripheral code that's only used in a support capacity. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
