[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    Re: [webkit-dev] Platform.h vs. makefiles
From:       Maciej Stachowiak <mjs () apple ! com>
Date:       2020-05-11 22:24:57
Message-ID: 2A0856FD-634E-4EE7-8721-1A8BF1259ED4 () apple ! com
[Download RAW message or body]



> On May 10, 2020, at 11:11 PM, Darin Adler <darin@apple.com> wrote:
> 
> > On May 10, 2020, at 10:07 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> > 
> > I think the best way to configure WebKit is to use a separate data file, neither \
> > a header nor a makefile or similar, that defines the options in a single place \
> > with clear syntax. Then everything else is generated from that. Such a system \
> > could cover runtime flags as well, which are even more scattered around the \
> > project than compile-time flags.
> 
> Sounds OK. I worry a little about defining yet another language, but otherwise I do \
> find this appealing. Perhaps some people would say that FeatureDefines.props from \
> cmake could be that file? 
> Not sure literally a single data file is the best way to do this across multiple \
> platforms/ports. I think PlatformEnableCocoa.h shows us that breaking this down can \
> be helpful.

> 
> One file that has the master list of all the settings, and all the default values. \
> Then other files that contain overlays for each port/configuration where they are \
> different from the default.


Yes, this is what I'd imagine. We could also add ability to inherit if we have \
configurations that want to share most but not all of their flag values. \
Additionally, we might need a way to express conditionals.

> My worry is that it could become complicated, like our TestExpectations files, \
> which were once simple.

It's possible, but hopefully it could be limited to only necessary complexity.

> > Moving logic from build files to the header is probably a move in the right \
> > direction, though of course it carries risk, particularly for less tested \
> > configurations.
> 
> Yes, I'm not suggesting rushing to do it all at once in a mass change.
> 
> But for new things especially on Apple's Cocoa platforms, I'd like to avoid \
> FeatureDefines.xcconfig and see new things in the PlatformEnableCocoa.h header file \
> instead. Unless the defines need to affect the build system and not just the C++ \
> code, I think the header file is superior.

That seems like a good direction.

 - Maciej

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


[prev in list] [next in list] [prev in thread] [next in thread]