> 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
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
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.
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
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
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
6 matches
Mail list logo
