On Thu, Jul 16, 2020 at 4:14 pm, Darin Adler wrote:
Let’s stop doing it that way. Just compile the files and have #if
inside the file.
I removed all conditional source files from the Xcode build system.
Let's do the same for the CMake build system.
— Darin
I agree we should do this.
> On Jul 16, 2020, at 3:33 PM, Adrian Perez de Castro wrote:
>
> enabling/disabling features changes the set of source files to
> build, which results in different source files being #included from each
> unifier source compilation unit.
Let’s stop doing it that way. Just compile the files and
On Thu, 16 Jul 2020 15:01:14 -0700, Darin Adler wrote:
> > On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro
> > wrote:
> >
> > It is not feasible to test unified builds for all the possible combinations
> > of
> > target architectures and set of features enabled at build time (there is a
>
Hi,
On Fri, 17 Jul 2020 06:52:54 +0900, Fujii Hironori
wrote:
> I'm glad to hear various opinions. Slack still can't beat mailing lists for
> technical discussions.
Aye, in my experience mailing lists are better because having to write down
thoughts in a slightly more structured way (in a mail
> On Jul 16, 2020, at 2:28 PM, Adrian Perez de Castro wrote:
>
> It is not feasible to test unified builds for all the possible combinations of
> target architectures and set of features enabled at build time (there is a
> combinatorial explosion of configurations). Keeping non-unified builds in
I'm glad to hear various opinions. Slack still can't beat mailing lists for
technical discussions.
On Fri, Jul 17, 2020 at 6:37 AM Adrian Perez de Castro
wrote:
> Also, some packagers used to carry assorted downstream patches for build
> issues related to unification build which have not been
I forgot to mention one tidbit...
On Fri, 17 Jul 2020 00:28:53 +0300, Adrian Perez de Castro
wrote:
> Hello everybody,
>
> On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler wrote:
> > > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross
> > > wrote:
> > >
> > > Non-unified build fixes are done to
Hello everybody,
On Thu, 16 Jul 2020 12:57:01 -0700, Darin Adler wrote:
> > On Jul 16, 2020, at 12:54 PM, Kirsling, Ross wrote:
> >
> > Non-unified build fixes are done to support *all* platforms, because
> > sudden unification shifts can happen anywhere.
>
> I’m not sure that benefit is worth
Results appear to be neutral on the page load time benchmark, so you should be
good on that front. I don’t know who the best person to vet the maturity of the
code is though, sorry.
Cheers,
Keith
> On Jul 13, 2020, at 11:38 AM, Noam Rosenthal wrote:
>
>
>
> On Mon, Jul 13, 2020 at 9:15 PM
> On Jul 16, 2020, at 12:54 PM, Kirsling, Ross wrote:
>
> Non-unified build fixes are done to support *all* platforms, because sudden
> unification shifts can happen anywhere.
I’m not sure that benefit is worth the additional code churn. I understand that
it’s frustrating to run into a
Non-unified build fixes are done to support *all* platforms, because sudden
unification shifts can happen anywhere. We can't currently perform a full
non-unified build on Mac since the CMake build only works up through JSC, so
Sony and Igalia have been performing this maintenance by hand on
The original question was, as I understood it, was do we need to support
non-unified builds as an essential requirement for a given port, and if so, why?
I’d like to finish answering that question, before we wonder off-topic and
consider whether supporting non-unified builds as an optional way
12 matches
Mail list logo
