Hi everyone,
Tup is a modern build system that enables fast and correct builds. I'm
pleased to announce the availability of Tup for building Firefox on Linux.
Compared to Make, building with Tup will result in faster incremental build
times and reduce the need for clobber builds. See the in-tree d
On Thu, Aug 30, 2018 at 6:04 PM, Michael Shal wrote:
>
>
> In this case, the 99:44 rebuild times look to be an artifact of how the
> outputs of GenerateServoStyleConsts.py are consumed by a large chunk of the
> Rust and C++ code. Attached is a graphviz .dot file for reference (
On Wed, Aug 29, 2018 at 11:36 AM, Boris Zbarsky wrote:
> On 8/29/18 10:32 AM, Ted Mielczarek wrote:
>
>> so it's possible that there are things here that are artifacts of our tup
>> build implementation.
>>
>
> Worth keeping in mind, thank you. Would that possibly account for the
> exactly-the-s
On Tue, Mar 7, 2017 at 5:40 PM, Randell Jesup wrote:
> >On 07/03/17 20:29, zbranie...@mozilla.com wrote:
> >
> >> I was just wondering if really two days of patches landing in Gecko
> should result
> >> in what seems like basically full rebuild.
> >>
> >> A clean build takes 65-70, a rebuild afte
On Fri, Dec 16, 2016 at 12:22 PM, Benoit Girard wrote:
> I don't believe anyone has taken to time to go through the CLOBBER hg
> history to find the causes and document them. That could be interesting.
>
>
A while back I wrote a series of blog posts on clobber builds that details
some of the reas
Hi all,
Builds will no longer publish to the gecko.v1 namespace in the Taskcluster
index. Please use gecko.v2 for any future projects that need to find
artifacts in Taskcluster.
Feel free to contact me with any questions!
Thanks,
-Mike
___
dev-platform
>
> Also, .h dependency proliferation is a real problem for build system
> performance, especially with the autogenerated mozilla-include.h (which
> contains things from every AC_DEFINE in configure.in - an add AC_DEFINE,
> invalidate everything). If you build the tips of mozilla-central from 24h
>
Hi Thomas,
> Am 26.11.2014 um 17:35 schrieb Michael Shal:
> > If the code for the library isn't changing, it's the build system's
> > responsibility to ensure that nothing is done. One of the problems is that
> > the build system we use (make) is so broken th
> Would it make sense to check in some of the libraries we build that we very
> rarely change, and that don’t have a lot of configure dependencies people
> twiddle with? (icu, pixman, cairo, vp8, vp9). This could speed up build
> times in our infrastructure and for developers. This doesn’t have to
> 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
> From: "Neil"
> There used to be a limitation that source files had to be in the VPATH.
> This limitation obviously does not apply to unified sources (the
> compiler will use the -I path to find the source.) so you shouldn't have
> a problem setting UNIFIED_SOURCES in a parent moz.build file. In
11 matches
Mail list logo
