On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro
wrote:
I would go even further and consider enabling unified builds only in
DEVELOPER_MODE (for CMake ports). For non-developer builds,
compilation time is much less important than limiting RAM usage to
reasonable levels. Using ninja'
At this point I would just go ahead and create the EWS bot. Even if
it's not going to be a default build configuration, we're still wasting
a bunch of time and effort to keep it working, and the EWS would help
fix that.
___
webkit-dev mailing lis
I can't speak for everyone, but the reason why I haven't been responding was
that the discussion went in circles, and didn't address the concerns raised.
There is new evidence showing that maintaining the non-unified build is very
hard. We knew that from the start, which is why the plan was to
This conversation has had some diverging threads (which is what makes mailing
list-based communication so difficult), but I'm disappointed that this should
mean that the crux of the conversation was lost.
There is no such thing as "not maintaining the non-unified build"; there never
has been. W
Ross, I didn't mean any disrespect.
I absolutely agree that this issue is not about the project supporting multiple
platforms.
What I disagree with is the statement that omitting includes necessary for
non-unified build is a mistake, or that it needs to be made visible. Fixing all
of these is
> There is no such thing as "not maintaining the non-unified build"; there
> never has been. We have covered that this is an *inherent* problem in a
> unified build mechanism and that this would be an issue even if Mac were the
> only platform.
It appears to me that we’re lacking the clarify in
6 matches
Mail list logo
