Hi,
I recently landed a new build backend that, if you opt-in to running it,
will make your non-C++ changes to Firefox more readily available in
local builds.
After you built Firefox normally once, and assuming you only changed
non-C++ code, you can now use the following command for a faster
incr
Mike Hommey wrote:
./mach build faster
So is this the complete opposite of ./mach build binaries?
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Fri, Oct 2, 2015 at 5:44 AM, Neil wrote:
> Mike Hommey wrote:
>
> ./mach build faster
>>
>> So is this the complete opposite of ./mach build binaries?
It complements `mach build binaries` and offers a mostly distinct set of
tasks, yes.
___
dev-pla
Nice! Out of curiosity, how does "faster" work? Does it just ignore build
targets/directories that involve native code?
FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my
low-end Surface Pro 3 (i3, 4GB)...
mach build: 7:38
mach build browser: 0:43
mach build toolkit: 1:42
m
Basically a set of build actions related to frontend development and known
by moz.build files are assembled in a single make file that contains a
single DAG and doesn't need to recurse into directories. See
python/mozbuild/mozbuild/backend/fastermake.py and /faster/Makefile
for the low-level detail
This is great progress!
I had hope that something like this would also include the 'build binaries'
DAG. It might make it slightly slower but it should still be very fast and
lessen the cognitive load. I was under the impression that 'build binaries'
at some point was a single DAG but it doesn't s
This is great progress!
I had hope that something like this would also include the 'build binaries'
DAG. It might make it slightly slower but it should still be very fast and
lessen the cognitive load. I was under the impression that 'build binaries'
at some point was a single DAG but it doesn't s
On Mon, Oct 05, 2015 at 03:08:15PM -0400, Benoit Girard wrote:
> This is great progress!
>
> I had hope that something like this would also include the 'build binaries'
> DAG. It might make it slightly slower but it should still be very fast and
> lessen the cognitive load. I was under the impress
On Fri, Oct 02, 2015 at 12:18:12PM -0700, Justin Dolske wrote:
> Nice! Out of curiosity, how does "faster" work? Does it just ignore build
> targets/directories that involve native code?
Greg answered this :)
> FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my
> low-end Su
9 matches
Mail list logo