On 2014-09-04, 1:37 AM, Botond Ballo wrote:
From: Boris Zbarsky bzbar...@mit.edu
To: dev-platform@lists.mozilla.org
Sent: Thursday, September 4, 2014 1:24:58 AM
Subject: Re: PSA: ./mach build subdirectory doesn't work reliably any longer
On 9/4/14, 12:51 AM, Joshua Cranmer wrote:
It sounds
On 2014-09-03, 11:47 PM, Nicholas Nethercote wrote:
On Wed, Sep 3, 2014 at 5:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
|mach build binaries| suffices most of the time
It really doesn't for the use case of not building the world when you
On Thu, Sep 4, 2014 at 8:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-09-04, 1:37 AM, Botond Ballo wrote:
From: Boris Zbarsky bzbar...@mit.edu
To: dev-platform@lists.mozilla.org
Sent: Thursday, September 4, 2014 1:24:58 AM
Subject: Re: PSA: ./mach build subdirectory doesn't
: Re: PSA: ./mach build subdirectory doesn't work reliably any
longer
On 9/4/14, 12:51 AM, Joshua Cranmer wrote:
It sounds to me like what you really want is support for a red squiggly
line in your IDE
Not quite, because red squiggly lines don't catch weird C++ namespacing
rules, lack
Mike Hommey wrote:
I guess this comes from installing test files.
Is there a build target that just installs installable files? (Although
presumably unless you're using Windows they should probably be symlinks
in which case you don't need to reinstall them.)
--
Warning: May contain
On Mon, Aug 25, 2014 at 5:48 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
- |mach build binaries| is awesome.
Here's an illustrative story. In my .bashrc file I have *18* aliases
for building subdirectories within Firefox: js, xpconnect, xpcom,
layout, etc. I used to use them all the
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
|mach build binaries| suffices most of the time
It really doesn't for the use case of not building the world when you
change a header and want to just rebuild the files that use the changed
part of the header...
I should also note that a
On Wed, Sep 03, 2014 at 08:52:30PM -0400, Boris Zbarsky wrote:
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
|mach build binaries| suffices most of the time
It really doesn't for the use case of not building the world when you change
a header and want to just rebuild the files that use the
On 9/3/14, 10:10 PM, Mike Hommey wrote:
Please file a bug with a timestamped log.
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1062668
And thank you!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Wed, Sep 3, 2014 at 5:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
|mach build binaries| suffices most of the time
It really doesn't for the use case of not building the world when you change
a header and want to just rebuild the files that
On Wed, Sep 3, 2014 at 8:47 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
It really doesn't for the use case of not building the world when you change
a header and want to just rebuild the files that use the changed part of the
header...
Thinking about this some more...
The standard
On Wed, Sep 3, 2014 at 9:26 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
What you're asking for is something beyond that -- you want sub-file
dependency tracking, because we (unfortunately) have some files that
are depended on by many other files. But in lieu of sub-file
dependency
On 9/4/14, 12:26 AM, Nicholas Nethercote wrote:
But in lieu of sub-file
dependency tracking you'll take manual overrides that emulate them by
doing partial builds, relying on your knowledge of the codebase to
know that those partial builds are safe.
This is a point worth clarifying.
I'm not
On 9/3/2014 11:45 PM, Boris Zbarsky wrote:
I mean, if I add a new virtual function to nsINode and then only
compile the subset of files that call the new function, I _know_ the
resulting build if I linked libxul is busted: different parts of it
think the vtable looks different. But this is
On 9/4/14, 12:51 AM, Joshua Cranmer wrote:
It sounds to me like what you really want is support for a red squiggly
line in your IDE
Not quite, because red squiggly lines don't catch weird C++ namespacing
rules, lack of conversion operators that should be present, etc...
-Boris
From: Boris Zbarsky bzbar...@mit.edu
To: dev-platform@lists.mozilla.org
Sent: Thursday, September 4, 2014 1:24:58 AM
Subject: Re: PSA: ./mach build subdirectory doesn't work reliably any longer
On 9/4/14, 12:51 AM, Joshua Cranmer wrote:
It sounds to me like what you really want
On 2014-08-27, 5:28 PM, Mike Hommey wrote:
On Wed, Aug 27, 2014 at 05:03:21PM -0400, Ehsan Akhgari wrote:
On 2014-08-27, 4:54 PM, Mike Hommey wrote:
On Wed, Aug 27, 2014 at 01:27:16PM -0400, Ehsan Akhgari wrote:
It still does that when finding the moz.build files, right? How about doing
On 2014-08-26, 11:54 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 11:34:29PM -0400, Ehsan Akhgari wrote:
On 2014-08-26, 6:05 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
Well, reading this thread, it doesn't seem mach build dir is broken for
the use
On Aug 27, 2014, at 5:18, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
On 2014-08-26, 11:54 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 11:34:29PM -0400, Ehsan Akhgari wrote:
On 2014-08-26, 6:05 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
On 8/27/14, 9:47 AM, Gregory Szorc wrote:
I interpret this this use case as building a related set of object files for the purpose
of quick/imprecise validation of changes to a specific component. So what you really want
is to build specific modules. Is that accurate?
That sounds like a
On 8/27/2014 6:52 AM, Benjamin Smedberg wrote:
On 8/27/14, 9:47 AM, Gregory Szorc wrote:
I interpret this this use case as building a related set of object
files for the purpose of quick/imprecise validation of changes to a
specific component. So what you really want is to build specific
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
There is additional cognitive load required to map a logical feature
into a set of directories. I would prefer this burden go away, as it
only breeds confusion and a higher barrier to contributing (new
contributors don't know these shortcuts so they
On 8/27/2014 7:39 AM, Benjamin Smedberg wrote:
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
There is additional cognitive load required to map a logical feature
into a set of directories. I would prefer this burden go away, as it
only breeds confusion and a higher barrier to contributing (new
On 08/27/2014 07:55 AM, Gregory Szorc wrote:
On 8/27/2014 7:39 AM, Benjamin Smedberg wrote:
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
Also, for the JS-centric use case you mentioned, if we invested in those
parts of the build system, we could probably get full tree builds with
no binary
On 2014-08-27 12:29 PM, Steve Fink wrote:
Maybe it's just me, but I'm having a lot of trouble following this
thread. Can someone spell out exactly what use cases we're talking about
here? Because I've heard several. Enumerating some of them:
1. I touched a file or files. Compile everything
On 8/27/14, 12:29 PM, Steve Fink wrote:
Enumerating some of them:
Let me add one:
6. I touched a file or files. Rebuild only the compiled-code tests
that test this stuff.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 8/27/14 10:02 AM, Boris Zbarsky wrote:
On 8/27/14, 12:29 PM, Steve Fink wrote:
Enumerating some of them:
Let me add one:
6. I touched a file or files. Rebuild only the compiled-code tests
that test this stuff.
Let's try to capture |mach build| workflows and requirements in an
On 2014-08-27, 10:55 AM, Gregory Szorc wrote:
On 8/27/2014 7:39 AM, Benjamin Smedberg wrote:
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
There is additional cognitive load required to map a logical feature
into a set of directories. I would prefer this burden go away, as it
only breeds
On 2014-08-27, 1:02 PM, Boris Zbarsky wrote:
On 8/27/14, 12:29 PM, Steve Fink wrote:
Enumerating some of them:
Let me add one:
6. I touched a file or files. Rebuild only the compiled-code tests
that test this stuff.
Do you mean something beyond:
$ ninja -t dom/bindings/test
?
On 8/27/14, 1:28 PM, Ehsan Akhgari wrote:
Do you mean something beyond:
$ ninja -t dom/bindings/test
I have no idea what that command line does, but note that mach build
dom/bindings/test doesn't compile the binding tests, or even regenerate
the test files. I _really_ wish it did.
-Boris
On 2014-08-27, 1:30 PM, Boris Zbarsky wrote:
On 8/27/14, 1:28 PM, Ehsan Akhgari wrote:
Do you mean something beyond:
$ ninja -t dom/bindings/test
I have no idea what that command line does, but note that mach build
dom/bindings/test doesn't compile the binding tests, or even regenerate
the
On 8/27/14, 1:46 PM, Ehsan Akhgari wrote:
Ah, that's pretty weird. I would consider that a build system bug.
../mach build content/media/webaudio/compiledtest for example does the
right thing.
Well.
The codegen runs in dom/bindings, not dom/bindings test.
So if I do
mach build
On Wednesday 2014-08-27 13:04 -0400, Zack Weinberg wrote:
2a. I touched a C++ header file which is included all over the
place. I anticipate that this change will break a specific set of
.cpp files. Recompile *those files* right now. Do not recompile
anything else. Do not link.
It is
On Wed, Aug 27, 2014 at 01:27:16PM -0400, Ehsan Akhgari wrote:
It still does that when finding the moz.build files, right? How about doing
something extremely simple such as: when you encounter a moz.build file,
record its path, build a ninja target for the path, and when you found any
On 2014-08-27, 4:54 PM, Mike Hommey wrote:
On Wed, Aug 27, 2014 at 01:27:16PM -0400, Ehsan Akhgari wrote:
It still does that when finding the moz.build files, right? How about doing
something extremely simple such as: when you encounter a moz.build file,
record its path, build a ninja target
On 2014-08-27, 1:57 PM, Boris Zbarsky wrote:
On 8/27/14, 1:46 PM, Ehsan Akhgari wrote:
Ah, that's pretty weird. I would consider that a build system bug.
../mach build content/media/webaudio/compiledtest for example does the
right thing.
Well.
The codegen runs in dom/bindings, not
On Wed, Aug 27, 2014 at 05:03:21PM -0400, Ehsan Akhgari wrote:
On 2014-08-27, 4:54 PM, Mike Hommey wrote:
On Wed, Aug 27, 2014 at 01:27:16PM -0400, Ehsan Akhgari wrote:
It still does that when finding the moz.build files, right? How about doing
something extremely simple such as: when you
On 2014-08-25, 6:17 PM, Mike Hommey wrote:
On Mon, Aug 25, 2014 at 06:06:17PM -0400, Ehsan Akhgari wrote:
On 2014-08-25, 4:49 PM, Gregory Szorc wrote:
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time,
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
Well, reading this thread, it doesn't seem mach build dir is broken for
the use people make of it, which is to build in a single directory. What
people want apparently, is more being able to build a single file or set
of files,
On 2014-08-26, 6:05 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
Well, reading this thread, it doesn't seem mach build dir is broken for
the use people make of it, which is to build in a single directory. What
people want apparently, is more being able
On Tue, Aug 26, 2014 at 11:34:29PM -0400, Ehsan Akhgari wrote:
On 2014-08-26, 6:05 PM, Mike Hommey wrote:
On Tue, Aug 26, 2014 at 10:40:39AM -0400, Ehsan Akhgari wrote:
Well, reading this thread, it doesn't seem mach build dir is broken for
the use people make of it, which is to build in a
On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
Unfortunately I don't really understand the reasons behind this, but if you
use this command, please know that it doesn't work properly any more, even
if it seems to work in some cases. AFAICT the workarounds are either doing
a full build or ./mach build
On 8/25/14, 8:37 AM, Gregory Szorc wrote:
How fast do no-op / light builds need to be for |mach build
subdirectory| to not exist?
About 10 seconds to compete with my usage[0] of |./mach build
subdirectory| for hacking on devtools.
Of course, getting even faster is always appreciated ;)
- Original Message -
From: Gregory Szorc g...@mozilla.com
To: Ehsan Akhgari ehsan.akhg...@gmail.com, dev-platform@lists.mozilla.org
Sent: Monday, August 25, 2014 8:37:42 AM
Subject: Re: PSA: ./mach build subdirectory doesn't work reliably any longer
The reason people do partial
- Original Message -
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no more errors
try to rebuild a few related directories, fixing errors there
then rebuild the entire tree, hopefully without
On 2014-08-25, 1:54 PM, Nathan Froyd wrote:
- Original Message -
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no more errors
try to rebuild a few related directories, fixing errors there
then
On Mon, Aug 25, 2014 at 8:27 PM, Bill McCloskey wmcclos...@mozilla.com wrote:
Even if a full no-op build took no time, partial builds are still useful.
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no
- Original Message -
Strawman idea: add support for:
mach check-syntax directory...
That will do nothing to reduce the overhead of the build system. Most
of the errors that Bill is talking about can be found the first time the
code is exercised by the compiler, so removing
On 8/25/14 11:00 AM, Ehsan Akhgari wrote:
On 2014-08-25, 1:54 PM, Nathan Froyd wrote:
- Original Message -
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no more errors
try to rebuild a few related
- Original Message -
FWIW, I've often made changes like this when touching files like
nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an
enum class! -- and I find just doing ./mach build binaries works fine.
It reports errors randomly from all over the tree, but that
On 25/8/2014, 14:16, Aryeh Gregor wrote:
FWIW, I've often made changes like this when touching files like
nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an
enum class! -- and I find just doing ./mach build binaries works fine.
It reports errors randomly from all over the
On 2014-08-25, 2:22 PM, Gregory Szorc wrote:
On 8/25/14 11:00 AM, Ehsan Akhgari wrote:
On 2014-08-25, 1:54 PM, Nathan Froyd wrote:
- Original Message -
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate
On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc g...@mozilla.com wrote:
On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
Unfortunately I don't really understand the reasons behind this, but if
you
use this command, please know that it doesn't work properly any more, even
if it seems to work in some
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still useful.
Often my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
...iterate until no more errors
try to
- Original Message -
On the other hand, if the build system automatically prioritized
.cpp dependencies ahead of .h dependencies and just automatically
built the things most likely to break first, I wouldn't have to
worry about this at all.
I'd be satisfied with that as well.
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still useful. Often
my workflow looks something like this:
change files in directory D
rebuild only D, get a list of errors to fix
On Mon, Aug 25, 2014 at 06:06:17PM -0400, Ehsan Akhgari wrote:
On 2014-08-25, 4:49 PM, Gregory Szorc wrote:
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still
useful. Often my
On Mon, Aug 25, 2014 at 12:24:53PM -0700, Eric Rescorla wrote:
On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc g...@mozilla.com wrote:
On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
Unfortunately I don't really understand the reasons behind this, but if
you
use this command, please know that
On 8/25/14 3:06 PM, Ehsan Akhgari wrote:
On 2014-08-25, 4:49 PM, Gregory Szorc wrote:
On 8/25/14 1:15 PM, L. David Baron wrote:
On Monday 2014-08-25 10:27 -0700, Bill McCloskey wrote:
Even if a full no-op build took no time, partial builds are still
useful. Often my workflow looks something
On Mon, Aug 25, 2014 at 3:18 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Aug 25, 2014 at 12:24:53PM -0700, Eric Rescorla wrote:
On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc g...@mozilla.com wrote:
On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
Unfortunately I don't really
On Mon, Aug 25, 2014 at 03:28:31PM -0700, Eric Rescorla wrote:
I experience much longer build times on my Macbook Air:
A no-op ./mach build binaries is 44 seconds.
That can't be a no-op.
Two builds one after the other give me:
18.639u 11.022s 0:40.86 72.5% 0+0k 34016+1852io
Unfortunately I don't really understand the reasons behind this, but if you
use this command, please know that it doesn't work properly any more, even
if it seems to work in some cases. AFAICT the workarounds are either doing
a full build or ./mach build binaries (I don't really know what things
On Fri, Aug 22, 2014 at 12:08:43PM -0400, Ehsan Akhgari wrote:
Unfortunately I don't really understand the reasons behind this, but if you
use this command, please know that it doesn't work properly any more, even
if it seems to work in some cases. AFAICT the workarounds are either doing
a
63 matches
Mail list logo
