I guess it depends on value of this (and feasibility of IDE highlighting based
on a generated source file) vs value of having a common approach for
compile-time and runtime flags. Runtime flags and their default values likely
can’t be effectively expressed in headers.
Separate file also lets u
> On May 10, 2020, at 11:11 PM, Darin Adler wrote:
>
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak 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 cle
I see substantial appeal in having a separate data file, however I'm not sure
if it can inform IDE parsing and syntax highlighting for code enabled/disabled
at compile time. Header files seem like they would get that right more often.
- Alexey
> 10 мая 2020 г., в 10:07 PM, Maciej Stachowiak
> On May 10, 2020, at 11:11 PM, Darin Adler wrote:
>
>> On May 10, 2020, at 10:07 PM, Maciej Stachowiak 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
> On May 10, 2020, at 10:07 PM, Maciej Stachowiak 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.
> Suc
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 sc
6 matches
Mail list logo
