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 m...@glandium.org wrote:
Hi,
A year ago, when unified compilation was introduced to speed up builds,
a couple issues were raised and we conservatively
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
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,
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 this is
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?
Another
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.
A year
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 think
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 (right includes
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 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
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
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 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
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
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 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
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
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
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
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
20 matches
Mail list logo
