[webkit-dev] Common build system (was Re: WebKit Wishes)

[Maciej Stachowiak]

On Jan 30, 2013, at 5:46 PM, Laszlo Gombos <laszlo.gombos at gmail.com> wrote:

> Hi !
> 
> 
> > I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time.
> >
> 
> I think this would be a nice related project, but I wouldn't
> necessarily want to lump the two goals together without understanding
> what we'd be shooting for first. From what I know, CMake's support for
> feature configuration is much more mature than what you can do w/ GYP.
> It could certainly be a good motivator, though.
> 
> My recent e-mail (https://lists.webkit.org/pipermail/webkit-dev/2013-January/023368.html) to the list was an attempt to address the feature configuration problem - assuming that that a single build system is not an option.  The idea was to use C macros to describe the rules for feature configurations and figure out a way to populate them to the various build systems (potentially using a C precompiler to eval the macros). Some of feature configuration flags does not need to be exposed to the build system these can just be #include-d to the source. I do not think that this is a technical superiors solution but perhaps it worth considering to discuss as it relies on tools and syntax we happened to already agree on and I felt that what might come out of it is better what we have now.

My past suggestion: have a separate Port.h header for every file, which turns on its set of PLATFORM, ENABLE and USE macros. Platform.h includes exclusively definitions of things that can be inferred from the build environment (like CPU, COMPILER, OS).

Port.h files could delegate. So for example we might have:

mac/Port.h --> cocoa/Port.h --> apple/Port.h --> default/Port.h

the default Port.h file would include the WebKit project's shared recommendations for what features should be on or off. If a flag ends up here and we don't know of any port disabling it, we might just remove it.

Including the right Port.h would be handled by include path magic.

That's my idea in a nutshell. It would put all configuration logic into the preprocessor instead of a mix of the preprocessor and various build systems.

Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130130/15a4dd76/attachment.html>