I have started to work on removing support for non-unified builds over in
bug 1121000.x
On Thu, Nov 27, 2014 at 8:12 PM, Mike Hommey wrote:
> Hi,
>
> A year ago, when unified compilation was introduced to speed up builds,
> a couple issues were raised and we conservatively restricted them out
>
On 2014-12-01 10:22 PM, Karl Tomlinson wrote:
On Fri, 28 Nov 2014 00:46:07 -0800, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right includes in the right sources,
mo
On 11/27/2014 9:28 PM, Ehsan Akhgari wrote:
Another point in favor of dropping support for non-unified builds is
that it frees up some infrastructure resources that is currently used to
test those builds, and also makes the builds in some configurations
where we build non-unified by default (such
On Fri, 28 Nov 2014 00:46:07 -0800, L. David Baron wrote:
> On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
>> The downside from doing so, though, is that non-unified build *will*
>> be broken, and code "purity" (right includes in the right sources,
>> mostly) won't be ensured. Do you think th
On 2014-11-28 11:18 AM, Nicolas B. Pierron wrote:
On 11/28/2014 03:36 PM, Ehsan Akhgari wrote:
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downsi
On 2014-11-28 11:02 AM, Jonathan Kew wrote:
On 28/11/14 14:36, Ehsan Akhgari wrote:
The question is: what do we gain from doing that, technical purity
aside? Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing
On 11/28/2014 03:36 PM, Ehsan Akhgari wrote:
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build
On 28/11/14 14:36, Ehsan Akhgari wrote:
The question is: what do we gain from doing that, technical purity
aside? Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing .cpp files, so keeping support for non-unifie
On 2014/11/28 18:26, Mike Hommey wrote:
On Fri, Nov 28, 2014 at 11:57:56AM +0900, ISHIKAWA,chiaki wrote:
On 2014/11/28 10:12, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of
On 2014-11-28 6:17 AM, Nicolas B. Pierron wrote:
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right in
On 11/28/2014 11:06 AM, Jonathan Kew wrote:
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right includes in the right sources,
mostly) won't be ensu
On 28/11/14 08:46, L. David Baron wrote:
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
The downside from doing so, though, is that non-unified build *will*
be broken, and code "purity" (right includes in the right sources,
mostly) won't be ensured. Do you think this is important enough to
On Fri, Nov 28, 2014 at 06:29:49PM +0900, Mike Hommey wrote:
> On Fri, Nov 28, 2014 at 12:46:07AM -0800, L. David Baron wrote:
> > On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
> > > The downside from doing so, though, is that non-unified build *will*
> > > be broken, and code "purity" (righ
On Fri, Nov 28, 2014 at 12:46:07AM -0800, L. David Baron wrote:
> On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
> > The downside from doing so, though, is that non-unified build *will*
> > be broken, and code "purity" (right includes in the right sources,
> > mostly) won't be ensured. Do you
On Fri, Nov 28, 2014 at 11:57:56AM +0900, ISHIKAWA,chiaki wrote:
> On 2014/11/28 10:12, Mike Hommey wrote:
> >Hi,
> >
> >A year ago, when unified compilation was introduced to speed up builds,
> >a couple issues were raised and we conservatively restricted them out
> >of aurora/beta/release/esr.
>
On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:
> The downside from doing so, though, is that non-unified build *will*
> be broken, and code "purity" (right includes in the right sources,
> mostly) won't be ensured. Do you think this is important enough to keep
> non-unified builds around?
An
On 2014/11/28 10:12, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of aurora/beta/release/esr.
A year later, it's time to revisit this decision, and since afaik we
haven't had
On 2014-11-27 9:16 PM, Ehsan Akhgari wrote:
On 2014-11-27 8:12 PM, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of aurora/beta/release/esr.
A year later, it's time to revisit
On 2014-11-27 8:12 PM, Mike Hommey wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of aurora/beta/release/esr.
A year later, it's time to revisit this decision, and since afaik we
haven't ha
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively restricted them out
of aurora/beta/release/esr.
A year later, it's time to revisit this decision, and since afaik we
haven't had problems specific to unified compilation o
20 matches
Mail list logo