On 18:23, Mon, 02 Dec, Ehsan Akhgari wrote:
As for identifying broken non-unified builds, can we configure one of
our mozilla-inbound platforms to be non-unified (like 32-bit Linux Debug)?
I think the answer to that question depends on how soon bug 942167 can
be fixed. Chris, any ideas?
Mike Hommey wrote:
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
Incidentally, in those two weeks, I did two attempts at building
without unified sources, resulting in me filing 4 bugs in different
modules for problems caused by 6 different landings[1]. I think it is time
to
On 11/29/13, 7:39 PM, Mike Hommey wrote:
I think it's time, 9 days before the merge, to think about whether we
want unified builds to ride the train or not. I'm almost tempted to
suggest that we disable unified builds on nightlies, but that would
probably hide the problems even more.
I don't
On 12/2/2013, 2:36 PM, Chris Peterson wrote:
On 11/29/13, 7:39 PM, Mike Hommey wrote:
I think it's time, 9 days before the merge, to think about whether we
want unified builds to ride the train or not. I'm almost tempted to
suggest that we disable unified builds on nightlies, but that would
On 12/2/2013, 2:26 PM, Taras Glek wrote:
Mike Hommey wrote:
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
Incidentally, in those two weeks, I did two attempts at building
without unified sources, resulting in me filing 4 bugs in different
modules for problems caused by 6
Ehsan Akhgari wrote:
On 12/2/2013, 2:26 PM, Taras Glek wrote:
Mike Hommey wrote:
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
Incidentally, in those two weeks, I did two attempts at building
without unified sources, resulting in me filing 4 bugs in different
modules for
On Mon, Dec 02, 2013 at 06:23:00PM -0500, Ehsan Akhgari wrote:
On 12/2/2013, 2:36 PM, Chris Peterson wrote:
On 11/29/13, 7:39 PM, Mike Hommey wrote:
I think it's time, 9 days before the merge, to think about whether we
want unified builds to ride the train or not. I'm almost tempted to
On Sat, Nov 30, 2013 at 6:56 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
I'm all for reducing usage of 'using' and in .cpp files I've been switching
to doing
namespace foo {
// my code
}
instead of
using namespace foo;
// my code
This only works if you
I'm all for reducing usage of 'using' and in .cpp files I've been switching
to doing
namespace foo {
// my code
}
instead of
using namespace foo;
// my code
where possible, as the latter leaks to other .cpp files in unified builds
and the former doesn't.
Regarding the
Hi,
Unified builds have been around for about two weeks. They are nice
because they make the build so much faster. On the other hand, we know
they currently break crash reports on mac (bug 943695), and can break
things in subtle ways (bug 942421, bug 943839). We don't know what
problems are still
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
Hi,
Unified builds have been around for about two weeks. They are nice
because they make the build so much faster. On the other hand, we know
they currently break crash reports on mac (bug 943695), and can break
things in subtle
If everyone puts using namespace foo; inside namespace mozilla {}, that
won't help much, right?
I'd prefer to minimize the source code changes required here. A tinderbox
non-unified build seems like the way to go.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
On Fri, Nov 29, 2013 at 8:01 PM, Mike Hommey m...@glandium.org wrote:
That is:
using namespace foo;
would be forbidden, but
namespace bar {
using namespace foo;
}
wouldn't. In most cases, bar could be mozilla anyways.
Most XPConnect stuff isn't in an explicit
13 matches
Mail list logo
