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 traces
On 2014-09-04, 2:03 PM, Jonas Sicking wrote:
On Thu, Sep 4, 2014 at 8:50 AM, Ehsan Akhgari wrote:
On 2014-09-04, 1:37 AM, Botond Ballo wrote:
From: "Boris Zbarsky"
To: dev-platform@lists.mozilla.org
Sent: Thursday, September 4, 2014 1:24:58 AM
Subject: Re: PSA: ./mach build do
On Thu, Sep 4, 2014 at 8:50 AM, Ehsan Akhgari wrote:
> On 2014-09-04, 1:37 AM, Botond Ballo wrote:
>>>
>>> From: "Boris Zbarsky"
>>> To: dev-platform@lists.mozilla.org
>>> Sent: Thursday, September 4, 2014 1:24:58 AM
>>> Subject: R
On 2014-09-03, 11:47 PM, Nicholas Nethercote wrote:
On Wed, Sep 3, 2014 at 5:52 PM, 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 w
On 2014-09-04, 1:37 AM, Botond Ballo wrote:
From: "Boris Zbarsky"
To: dev-platform@lists.mozilla.org
Sent: Thursday, September 4, 2014 1:24:58 AM
Subject: Re: PSA: ./mach build doesn't work reliably any longer
On 9/4/14, 12:51 AM, Joshua Cranmer 🐧 wrote:
It sounds to me like
> From: "Boris Zbarsky"
> To: dev-platform@lists.mozilla.org
> Sent: Thursday, September 4, 2014 1:24:58 AM
> Subject: Re: PSA: ./mach build doesn't work reliably any longer
>
> On 9/4/14, 12:51 AM, Joshua Cranmer 🐧 wrote:
> > It sounds to me like wh
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
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 sti
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 tr
On Wed, Sep 3, 2014 at 9:26 PM, Nicholas Nethercote
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 tracking you'll take
On Wed, Sep 3, 2014 at 8:47 PM, Nicholas Nethercote
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 ideal build sys
On Wed, Sep 3, 2014 at 5:52 PM, 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 ch
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
https://lists.mozilla.or
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
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 comple
On Mon, Aug 25, 2014 at 5:48 PM, Nicholas Nethercote
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 time... but I only now
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
somet
On 8/27/14, 5:05 PM, Ehsan Akhgari wrote:
Right, but that should now be fixed right?
Hmm. Yes, it looks like this got fixed in the last few days. Excellent!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.o
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
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 dom/bindin
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 fo
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
> SOU
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 i
On Wed, Aug 27, 2014 at 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.
+1. I do this constantly for the WebRTC code an
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 dom/binding
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: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.
-Bori
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 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 confusio
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
etherpad
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 withi
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
https:
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
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 contributin
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 sit
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 speci
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 comp
> On Aug 27, 2014, at 5:18, Ehsan Akhgari 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:
>> Well, r
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 p
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 buil
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 to
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 fil
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, par
A few thoughts.
- |mach build binaries| is awesome.
- The build team has a difficult job. Dealing with both "the build
system sucks" and "don't make me change my workflow" is hard. The real
wins will come when the build system is fully uncoupled from |make|,
which is a big task. glandium and froy
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+
On Mon, Aug 25, 2014 at 3:18 PM, Mike Hommey 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 wrote:
> >
> > > On 8/22/14 9:08 AM, Ehsan Akhgari wrote:
> > >
> > >> Unfortunately I don't really understand the reasons behin
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 li
On Mon, Aug 25, 2014 at 12:24:53PM -0700, Eric Rescorla wrote:
> On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc 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 i
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.
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 like this:
change files in directory D
rebu
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
...it
- 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.
> St
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
On Mon, Aug 25, 2014 at 8:37 AM, Gregory Szorc 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 cases.
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 until
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 tree,
- 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 t
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 d
- Original Message -
> > Strawman idea: add support for:
> >
> >mach check-syntax ...
>
> 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 t
On Mon, Aug 25, 2014 at 8:27 PM, 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 t
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 rebuil
- 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 with
- Original Message -
> From: "Gregory Szorc"
> To: "Ehsan Akhgari" , dev-platform@lists.mozilla.org
> Sent: Monday, August 25, 2014 8:37:42 AM
> Subject: Re: PSA: ./mach build doesn't work reliably any longer
>
> The reason people do partial
On 8/25/14, 8:37 AM, Gregory Szorc wrote:
How fast do "no-op" / light builds need to be for |mach build
| to not exist?
About 10 seconds to compete with my usage[0] of |./mach build
| for hacking on devtools.
Of course, getting even faster is always appreciated ;)
[0] Actual command I ru
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 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
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 t
67 matches
Mail list logo
