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

List:       webkit-dev
Subject:    Re: [webkit-dev] Platform.h vs. makefiles
From:       Michael Saboff <msaboff () apple ! com>
Date:       2020-05-11 16:18:50
Message-ID: E7BB0085-04E0-4962-B344-E0A144BDDC86 () 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. 
> My worry is that it could become complicated, like our TestExpectations files, \
> which were once simple.

One challenge with a data file approach is that all build systems need to be aware \
that it is the root dependency for most targets.  As such I don't think it make sense \
to invent a new format, but to possibly refine the PlatformEnable*.h hierarchy.  \
Perhaps a new PlatformOverrides.h file that would only contain the overrides while \
the current PlatformEnable*.h contain the defaults.

> > 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. 
> — Darin
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

- Michael
_______________________________________________
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]