Re: RFC: what's the correct behavior for Visual Studio projects and unified builds?

Intellisense and other code navigation things all work now in the generated project file. This is awesome, thanks! Chris Pearce. On Friday, March 13, 2015 at 10:13:55 AM UTC+13, Nathan Froyd wrote: > On Thu, Mar 12, 2015 at 5:39 AM, Chris Pearce wrote: > > > Breaking VisualStudio Intellisens

Re: RFC: what's the correct behavior for Visual Studio projects and unified builds?

On Thu, Mar 12, 2015 at 5:39 AM, Chris Pearce wrote: > Breaking VisualStudio Intellisense also broke most of the code navigation > things that make VisualStudio awesome. I don't build with VisualStudio, I > build with the command line because I like to build && run, and I like to > pipe the outpu

Re: RFC: what's the correct behavior for Visual Studio projects and unified builds?

reasonable way for you with unified builds without the patch for bug 1122812? 2) You're saying Intellisense does _not_ work in a reasonable way for you on trunk right now? We should backout whatever we have to to fix this. I think Nathan is trying to figure out what that "whatever

Re: RFC: what's the correct behavior for Visual Studio projects and unified builds?

he recent transition to only supporting unified builds, some people were apparently concerned about how this would affect Visual Studio projects (i.e. Intellisense), since the Visual Studio project files generated via |mach build-backend| only listed the individual source files, and not the unif

RFC: what's the correct behavior for Visual Studio projects and unified builds?

Hi all, When discussing the recent transition to only supporting unified builds, some people were apparently concerned about how this would affect Visual Studio projects (i.e. Intellisense), since the Visual Studio project files generated via |mach build-backend| only listed the individual source

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 >>

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 cc

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 locally to make sure I can avoid re-compilation of touched but not modifi

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 combinatio

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 combination can help me do the source level debugging if

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

es_per_unification = 1). This would not depend on mozconfig and configure support for --disable-unified-compilation. I prefer the environment variable. But I urge everyone to please wait to see if we start getting fixes for non-unified builds from now on

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

gt;>>>> > >>>>>Why is the configure option being removed? > >>>> > >>>>Because unsupported build configurations that are *guaranteed* to not > >>>>be maintained are not worth keeping around. I am 90% sure that > >>>>--disab

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 +++ b/python/mozbuild/mozbuild/backend/recursivemake.p

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On Fri, Jan 16, 2015 at 3:17 PM, Ehsan Akhgari 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 UnifiedXXX.cpp files > to the pr

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

unsupported build configurations that are *guaranteed* to not be maintained are not worth keeping around. I am 90% sure that --disable-unified-compilation would have been broken since yesterday. :-) But that's not the point. I totally agree that non-unified builds will get broken immediately and

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 planni

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

>> I commented in the bug, but I guess this is probably a better forum. >>>> >>>> Why is the configure option being removed? >>> >>> Because unsupported build configurations that are *guaranteed* to not >>> be maintained are not worth keeping around

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

keeping around. I am 90% sure that --disable-unified-compilation would have been broken since yesterday. :-) 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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On Thu, Jan 15, 2015 at 4:30 PM, Steve Fink 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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

at are *guaranteed* to not > be maintained are not worth keeping around. I am 90% sure that > --disable-unified-compilation would have been broken since yesterday. > :-) But that's not the point. I totally agree that non-unified builds will get broken immediately and will stay bro

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 co

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 wrote: > > On 2015-01-15 5:57

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 list

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 wrote: > > On Thu, Jan 15, 2015 at 02:11:16PM -0500, Benjamin Kelly wrote: >> For what its worth, you can

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 commen

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On Wed, Jan 14, 2015 at 8: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 m

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 pl

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 planning to follow-up with remo

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 > unified files exceed some cl

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On 01/15/2015 09:31 AM, Bobby Holley wrote: > On Wed, Jan 14, 2015 at 5: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 wit

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

valid C++, how should they do it after this change? 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 unified files exceed some clang analysis

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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-compilati

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On Wed, Jan 14, 2015 at 5: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 b

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 compile

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 commente

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

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 prob

PSA: Non-unified builds no longer occurring on central/inbound and friends

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.

Non-unified builds now running periodically on all trees

catch build problems that are masked by unifying the source files. By doing regular builds with unified sources disabled we'll have a smaller regression window to help pinpoint the changes which broke the non-unified configuration. Once we shake out all the issues with the linux64 non-unifi

Disabling unified builds on mozilla-inbound debug builds Was: Thinking about the merge with unified build

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

Re: Unified builds

Ehsan Akhgari wrote: It's hard to say exactly what's going on here without knowing more about how this build is produced. These are intermittent failures on TBPL, mostly starred by philor. It would be really great if you could file a bug about this with more details on how to reproduce this

Re: Unified builds

On 2013-11-23 7:22 AM, ISHIKAWA,chiaki wrote: (2013/11/23 1:41), Ehsan Akhgari wrote: On 2013-11-21 1:12 PM, ISHIKAWA,chiaki wrote: (2013/11/22 2:17), Ehsan Akhgari wrote: FWIW if this proves to be common, it's a huge problem since it would affect our crash stats etc... :( Well, if the prob

Re: Unified builds

(2013/11/23 1:41), Ehsan Akhgari wrote: On 2013-11-21 1:12 PM, ISHIKAWA,chiaki wrote: (2013/11/22 2:17), Ehsan Akhgari wrote: FWIW if this proves to be common, it's a huge problem since it would affect our crash stats etc... :( Well, if the problem is related to the symptom that I observed w

Re: Unified builds

On Fri, Nov 22, 2013 at 07:24:14PM -0500, Ehsan Akhgari wrote: > On 2013-11-22 4:25 PM, Gregory Szorc wrote: > >On Nov 22, 2013, at 13:16, Ehsan Akhgari wrote: > > > >>On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky wrote: > >> > >>>On 11/22/13 11:41 AM, Ehsan Akhgari wrote: > >>> > Hmm to the

Re: Unified builds

On 2013-11-22 4:25 PM, Gregory Szorc wrote: On Nov 22, 2013, at 13:16, Ehsan Akhgari wrote: On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky wrote: On 11/22/13 11:41 AM, Ehsan Akhgari wrote: Hmm to the best of my knowledge, we don't generate the *.i files unless if you explicitly request th

Re: Unified builds

On Nov 22, 2013, at 13:16, Ehsan Akhgari wrote: > On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky wrote: > >> On 11/22/13 11:41 AM, Ehsan Akhgari wrote: >> >>> Hmm to the best of my knowledge, we don't generate the *.i files unless >>> if you explicitly request them. Is that what you did in th

Re: Unified builds

On Fri, Nov 22, 2013 at 1:02 PM, Boris Zbarsky wrote: > On 11/22/13 11:41 AM, Ehsan Akhgari wrote: > >> Hmm to the best of my knowledge, we don't generate the *.i files unless >> if you explicitly request them. Is that what you did in that build? >> > > ccache obvously always generates .i files,

Re: Unified builds

On 11/22/13 11:41 AM, Ehsan Akhgari wrote: Hmm to the best of my knowledge, we don't generate the *.i files unless if you explicitly request them. Is that what you did in that build? ccache obvously always generates .i files, since those are what it uses as its cache key. And then it compil

Re: Unified builds

On 2013-11-22 8:33 AM, Mike Hommey wrote: On Thu, Nov 14, 2013 at 05:49:33PM -0500, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead o

Re: Unified builds

On 2013-11-21 1:12 PM, ISHIKAWA,chiaki wrote: (2013/11/22 2:17), Ehsan Akhgari wrote: FWIW if this proves to be common, it's a huge problem since it would affect our crash stats etc... :( Well, if the problem is related to the symptom that I observed with the use of -gsplit-dwarf option with

Re: Unified builds

On Thu, Nov 14, 2013 at 05:49:33PM -0500, Ehsan Akhgari wrote: > I've started to work on a project in my spare time to switch us to use > unified builds for C/C++ compilation. The way that unified builds work is > by using the UNIFIED_SOURCES instead of the SOURCES variable in moz

Re: Unified builds

On 2013-11-21 10:06 AM, Michael Shal wrote: From: "Gregory Szorc" Unified sources have probably saved sufficient CPU cycles across all of automation to more than offset having a non-unified build-only job. I'll defer to the Platform Team (Ehsan?) to request that from Release Engineering. How m

Re: Unified builds

On 2013-11-21 12:00 PM, ISHIKAWA,chiaki wrote: (2013/11/22 1:47), Ehsan Akhgari wrote: On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote: (2013/11/15 7:49), Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. Th

Re: Unified builds

On 11/21/13, 7:06 AM, Michael Shal wrote: From: "Gregory Szorc" Unified sources have probably saved sufficient CPU cycles across all of automation to more than offset having a non-unified build-only job. I'll defer to the Platform Team (Ehsan?) to request that from Release Engineering. How man

Re: Unified builds (regarding periodic clobber)

Gregory Szorc writes: > Do we need periodic clobber? It's just wallpapering over legit > clobber-needed issues, which doesn't exactly help us fix them. The problem is that unfixed bugs in dependences mean that code bugs can sometimes not show up until the next clobber. There is then a huge regre

Re: Unified builds

> From: "Gregory Szorc" > Unified sources have probably saved sufficient CPU cycles across all of > automation to more than offset having a non-unified build-only job. I'll > defer to the Platform Team (Ehsan?) to request that from Release > Engineering. How many CPU cycles would we have saved ac

Re: Unified builds (regarding periodic clobber)

On 11/21/13, 8:40 AM, Ehsan Akhgari wrote: On 2013-11-21 10:44 AM, Ed Morley wrote: On 21 November 2013 15:38:28, Ehsan Akhgari wrote: We don't, we clobber periodically. I'm not sure why that is better than never clobbering... We've been force-clobbering 1-2 times a day in automation for sev

Re: Unified builds

On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote: (2013/11/15 7:49), Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES var

Re: Unified builds

On 21 November 2013 15:38:28, Ehsan Akhgari wrote: We don't, we clobber periodically. I'm not sure why that is better than never clobbering... We've been force-clobbering 1-2 times a day in automation for several months now sadly, due to bug 928195 and similar prior. (Patches almost ready to

Re: Unified builds

On 2013-11-21 10:44 AM, Ed Morley wrote: On 21 November 2013 15:38:28, Ehsan Akhgari wrote: We don't, we clobber periodically. I'm not sure why that is better than never clobbering... We've been force-clobbering 1-2 times a day in automation for several months now sadly, due to bug 928195 and

Re: Unified builds

(2013/11/15 7:49), Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build s

Re: Unified builds (regarding periodic clobber)

> On 11/21/13, 8:40 AM, Ehsan Akhgari wrote: >> Yes, but our periodic clobber has been in effect long before that bug >> (and in fact for as long as I can remember.) Yes, but it's only once a week rather than a couple of times a day :-) On 21/11/2013 16:45, Gregory Szorc wrote: Do we need perio

Re: Unified builds

(2013/11/22 1:47), Ehsan Akhgari wrote: On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote: (2013/11/15 7:49), Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by usin

Re: Unified builds

(2013/11/22 2:17), Ehsan Akhgari wrote: FWIW if this proves to be common, it's a huge problem since it would affect our crash stats etc... :( Well, if the problem is related to the symptom that I observed with the use of -gsplit-dwarf option with ccache, then we may be in for a big surprise.

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 21/11/2013 01:12, Daniel Glastonbury wrote: I followed your advice. Quit Xcode, created .lldbinit, ./mach clobber && ./mach build and my missing breakpoints are back. Thank you. You're welcome. ___ dev-platform mailing list dev-platform@lists.moz

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 21/11/2013 03:16, Ehsan Akhgari wrote: On 2013-11-20 6:37 PM, Jonathan Watt wrote: I'll update the OS X Debugging wiki page. Since it seems setting target.inline-breakpoint-strategy can basically be made to work I don't plan on contacting the LLDB guys right now. Can we add our own lldbinit

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 2013-11-20 6:37 PM, Jonathan Watt wrote: On 20/11/2013 18:48, Ehsan Akhgari wrote: On 2013-11-20 1:33 PM, Jonathan Watt wrote: I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a he

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On Thursday, November 21, 2013 9:37:05 AM UTC+10, Jonathan Watt wrote: > When I first added the line to set target.inline-breakpoint-strategy in my > > ~/.lldbinit as per: > > > >http://lldb.llvm.org/troubleshooting.html > > > > it didn't work, even after restarting Xcode and starting a

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On 20/11/2013 18:48, Ehsan Akhgari wrote: On 2013-11-20 1:33 PM, Jonathan Watt wrote: I'm still investigating this, and will contact them once I understand a bit better what's going on. For now I still wanted to give other LLDB using mozilla devs a heads-up though. Thanks! Please keep us in t

Re: Unified builds

On 2013-11-20 5:17 PM, Gregory Szorc wrote: On 11/20/13, 2:02 PM, Zack Weinberg wrote: On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree:

Re: Unified builds

On 11/20/13, 2:02 PM, Zack Weinberg wrote: On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h

Re: Unified builds

On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h/etc. #undef MyFunction #endif A small not

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

I just did a unified and non-unified build on my windows desktop -- non SSD. VS2012, using mozmake. Full clobber. (mozmake -s -j8) Unified: 20 min Non-Unified: 36 min This is huge! I was curious about the cost for incremental builds... touch gfx/2d/Factory.cpp (part of a unified file), r

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

ug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can handle setting breakpoints in header files, they should be able

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

s sense to have every developer on a new mac platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

c platform reverting all the UNIFIED_SOURCES stuff. I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Given the fact that they can hand

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

the UNIFIED_SOURCES stuff. >> > > I think somebody needs to file a bug with the lldb project and describe > the problem to them and ask them for a fix. We are not the only project > using unified builds, so this problem is not specific to Mozilla. Given > the fact that they can

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

ery developer on a new mac platform > reverting all the UNIFIED_SOURCES stuff. > I think somebody needs to file a bug with the lldb project and describe the problem to them and ask them for a fix. We are not the only project using unified builds, so this problem is not specific to Mozilla. Give

Re: UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

On Wed, Nov 20, 2013 at 10:01 AM, Jonathan Watt wrote: > I may end up being the guinea pig that is perpetually having his builds > broken because he has to have a patch applied to revert all UNIFIED_SOURCES > lines back to SOURCES lines in order to debug anything... > Given that new versions of

UNIFIED_SOURCES breaks breakpoints in LLDB (Was: Unified builds)

Just a heads-up for other LLDB users... The last few days I've been driven nuts by Xcode failing to stop at some breakpoints (it just lists them as pending). I've now tracked this down to the use of UNIFIED_SOURCES. The issue is explained here: http://lldb.llvm.org/troubleshooting.html Unf

Re: Unified builds

On 11/14/13, 2:49 PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the

Re: Unified builds

On Tuesday 2013-11-19 17:08 +1300, Robert O'Callahan wrote: > Fortunately two static variables with the same name in the same translation > unit is an error in C++, at least with gcc. Ah, indeed. I'd tested in C, where it wasn't an error, but I also see an error with gcc in C++. -David -- 𝄞

Re: Unified builds

On Tue, Nov 19, 2013 at 4:04 PM, L. David Baron wrote: > I expect that otherwise we'd get pretty frequent bustage with people > forgetting to add #includes, and that bustage would then show up > when we add or remove files, which would make it a huge pain to add > or remove files. > > But I'm act

Re: Unified builds

PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build system creates files

Re: Unified builds

ct in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build system creates files such as: // Unified_cpp_path_0.cpp #include "S

Re: Unified builds

M, Ehsan Akhgari > > >>wrote: > > >>>I've started to work on a project in my spare time to switch us to use > > >>>unified builds for C/C++ compilation. The way that unified builds work > > >>>is > > >>>by using the UNIF

Re: Unified builds

n a project in my spare time to switch us to use > >>>unified builds for C/C++ compilation. The way that unified builds work is > >>>by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build > >>>files. With that, the build system create

Re: Unified builds

On 2013-11-17 7:50 PM, L. David Baron wrote: On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote: On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified b

Re: Unified builds

On 2013-11-17 7:45 PM, Jonas Sicking wrote: On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead o

Re: Unified builds

On 2013-11-18 9:53 AM, Boris Zbarsky wrote: On 11/18/13 9:49 AM, Benoit Jacob wrote: 2) Keep these cpp files, that #include system headers, in plain old SOURCES, not in UNIFIED_SOURCES. Maybe that's the right way to go. Enforce that no .cpp file that's in UNIFIED_SOURCES ever includes the b

Re: Unified builds

s until we have more data on how often it's a problem in practice. The bindings code is "special" in that you have a single directory pulling in headers from all over Gecko and files are added or removed from that directory frequently. Indeed. If unified builds turn out to cause t

Re: Unified builds

On 2013-11-17 7:53 PM, Jonas Sicking wrote: On Sat, Nov 16, 2013 at 1:34 AM, Ms2ger wrote: One issue I only thought of today: this means that Source2.cpp can use all headers included into Source1.cpp–until enough files are added between Source1 and Source2 that Source2 ends up in the next unif

Re: Unified builds

On 2013-11-18 4:33 AM, Neil wrote: Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With

Re: Unified builds

On 2013-11-17 5:39 PM, Mike Hommey wrote: On Sat, Nov 16, 2013 at 10:34:38AM +0100, Ms2ger wrote: On 11/14/2013 11:49 PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work

Re: Unified builds

#x27;s a problem in practice. The bindings code is "special" in that you have a single directory pulling in headers from all over Gecko and files are added or removed from that directory frequently. If unified builds turn out to cause too many problems, turning them off is trivial. Most of

Re: Unified builds

whenever you add a new one. If we had a mozconfig flag to disable unified builds (i.e. treat UNIFIED_SOURCES as SOURCES), interested parties can run non-unified builds to find and fix accidental header dependencies at their leisure. I agree with Ehsan, however, that we don't need to add

Re: Unified builds

Boris Zbarsky wrote: On 11/17/13 5:26 PM, Ehsan Akhgari wrote: I don't think that we need to try to fix this problem any more than the general problem of denoting our dependencies explicitly. It's common for you to remove an #include from a header and find dozens of .cpp files in the tree t

Re: Unified builds

On 11/18/13 9:49 AM, Benoit Jacob wrote: 2) Keep these cpp files, that #include system headers, in plain old SOURCES, not in UNIFIED_SOURCES. Maybe that's the right way to go. Enforce that no .cpp file that's in UNIFIED_SOURCES ever includes the broken system headers, like we already do fo

Re: Unified builds

2013/11/18 Boris Zbarsky > On 11/17/13 5:26 PM, Ehsan Akhgari wrote: > >> I don't think that we need to try to fix this problem any more than the >> general problem of denoting our dependencies explicitly. It's common for >> you to remove an #include from a header and find dozens of .cpp files i

  1   2   >