On 2015/02/03 15:24, Mike Hommey wrote:
On Tue, Feb 03, 2015 at 02:27:52PM +0900, ISHIKAWA,chiaki wrote:
I did a non-unified build and saw the expected failure.
This is a summary of what I saw.
Background:
I may need to modify and debug basic I/O routines on local PC, and so
want to avoid
On Tue, Feb 03, 2015 at 02:27:52PM +0900, ISHIKAWA,chiaki wrote:
I did a non-unified build and saw the expected failure.
This is a summary of what I saw.
Background:
I may need to modify and debug basic I/O routines on local PC, and so
want to avoid unnecessary compilation. I use ccache
On 2015-01-17 9:58 AM, ISHIKAWA,chiaki wrote:
On 2015/01/16 1:08, Jonathan Kew wrote:
On 15/1/15 15:56, ISHIKAWA,chiaki wrote:
Debugging using gdb will be very difficult when the unified build
creates a source file on the fly (but it is removed, correct?).
No sane compiler/debugger
On Thu, Jan 15, 2015 at 06:39:56PM +0100, Sylvestre Ledru wrote:
On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
On 2015/01/15 10:37, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to
On 2015-01-16 2:10 AM, Steve Fink wrote:
On 01/15/2015 04:52 PM, Ehsan Akhgari wrote:
On 2015-01-15 7:30 PM, Steve Fink wrote:
On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
On 2015-01-14 8:37 PM, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only
On Fri, Jan 16, 2015 at 3:17 PM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:
Ben Turner pointed out to me on IRC yesterday that Visual Studio will have
a hard time because of this, and he's right, but that's because the Visual
Studio project generator is broken. It should add the
On 1/16/15 12:17 PM, Ehsan Akhgari wrote:
diff --git a/python/mozbuild/mozbuild/backend/recursivemake.py
b/python/mozbuild/mozbuild/backend/recursivemake.py
index 608f6f5..de754b6 100644
--- a/python/mozbuild/mozbuild/backend/recursivemake.py
+++
On Fri, Jan 16, 2015 at 03:17:38PM -0500, Ehsan Akhgari wrote:
On 2015-01-16 2:10 AM, Steve Fink wrote:
On 01/15/2015 04:52 PM, Ehsan Akhgari wrote:
On 2015-01-15 7:30 PM, Steve Fink wrote:
On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
On 2015-01-14 8:37 PM, Steve Fink wrote:
On 01/14/2015
On 2015-01-16 5:06 PM, Chris Peterson wrote:
On 1/16/15 12:17 PM, Ehsan Akhgari wrote:
diff --git a/python/mozbuild/mozbuild/backend/recursivemake.py
b/python/mozbuild/mozbuild/backend/recursivemake.py
index 608f6f5..de754b6 100644
--- a/python/mozbuild/mozbuild/backend/recursivemake.py
+++
On Wed, Jan 14, 2015 at 5:37 PM, Steve Fink sf...@mozilla.com wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option
On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
On 2015/01/15 10:37, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation
On 01/15/2015 09:31 AM, Bobby Holley wrote:
On Wed, Jan 14, 2015 at 5:37 PM, Steve Fink sf...@mozilla.com
mailto:sf...@mozilla.com wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified
compilation. I
am planning to
On 1/14/15 5:37 PM, Steve Fink wrote:
Why is the configure option being removed? I understand always building
unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through occasionally and make our codebase
On 2015/01/15 10:37, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.
I
On 15/1/15 15:56, ISHIKAWA,chiaki wrote:
Debugging using gdb will be very difficult when the unified build
creates a source file on the fly (but it is removed, correct?).
No sane compiler/debugger combination can help me do
the source level debugging if the source code that the compiler
On Wed, Jan 14, 2015 at 8:37 PM, Steve Fink sf...@mozilla.com wrote:
Why is the configure option being removed? I understand always building
unified in automation, but not having a straightforward way at all to
see if your code is buggy seems... suboptimal. If someone wants to go
through
On 2015-01-15 1:50 PM, Steve Fink wrote:
On 01/15/2015 09:39 AM, Sylvestre Ledru wrote:
On 15/01/2015 16:56, ISHIKAWA,chiaki wrote:
On 2015/01/15 10:37, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am
On 2015-01-15 1:49 PM, Daniel Holbert wrote:
On 01/15/2015 09:46 AM, Chris Peterson wrote:
Another small benefit of optional non-unified builds is that clang does
a better job of reporting -Wunused-variable warnings with smaller
translation units. I assume that the number of identifiers in the
On 2015-01-14 8:37 PM, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.
I
On 2015-01-15 6:46 PM, Seth Fowler wrote:
It wouldn’t be true of, say, a mach argument specifying directories that should
be built non-unified.
Not that it matters nearly as much now that we’ve made the decision not to
support non-unified builds.
Yeah that's true, but that mach command
On Thu, Jan 15, 2015 at 02:11:16PM -0500, Benjamin Kelly wrote:
For what its worth, you can still verify individual directories by changing
moz.build to use SOURCES instead of UNIFIED_SOURCES.
On Thu, Jan 15, 2015 at 02:21:25PM -0500, Ehsan Akhgari wrote:
Switch the UNIFIED_SOURCES variable to
On 2015-01-15 5:57 PM, Seth Fowler wrote:
What’s a bit unfortunate about these approaches is that you can accidentally
qref them into your patch. I’ve managed to do so repeatedly.
That's true of any local change, right?
___
dev-platform mailing
It wouldn’t be true of, say, a mach argument specifying directories that should
be built non-unified.
Not that it matters nearly as much now that we’ve made the decision not to
support non-unified builds.
On Jan 15, 2015, at 3:36 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On
What’s a bit unfortunate about these approaches is that you can accidentally
qref them into your patch. I’ve managed to do so repeatedly.
- Seth
On Jan 15, 2015, at 2:52 PM, Mike Hommey m...@glandium.org wrote:
On Thu, Jan 15, 2015 at 02:11:16PM -0500, Benjamin Kelly wrote:
For what its
On 2015-01-15 7:30 PM, Steve Fink wrote:
On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
On 2015-01-14 8:37 PM, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support
On Thu, Jan 15, 2015 at 4:30 PM, Steve Fink sf...@mozilla.com wrote:
But that's not the point. I totally agree that non-unified builds will
get broken immediately and will stay broken most of the time. That's not
in question. The point is how hard it is for someone who comes along and
wants
On 01/15/2015 04:52 PM, Ehsan Akhgari wrote:
On 2015-01-15 7:30 PM, Steve Fink wrote:
On 01/15/2015 11:21 AM, Ehsan Akhgari wrote:
On 2015-01-14 8:37 PM, Steve Fink wrote:
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified
compilation. I
am
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.
This puts an end to the issue of burning non-unified builders when pushing.
On 01/14/2015 11:26 AM, Ehsan Akhgari wrote:
From now on, the only supported build mode is unified compilation. I
am planning to follow-up with removing support for the
--disable-unified-compilation configure option altogether in bug 1121000.
I commented in the bug, but I guess this is
29 matches
Mail list logo
