On Sat, Jul 18, 2015 at 3:55 AM, Benoit Girard wrote:
> Why not continue to make piecework improvements? My understanding is `mach
> build binaries` now handles .cpp, .h changes only. Why not slowly extend
> this piece-wise to include .js[m], ipdl, idl, webidl in milestones?
glandium has done and
Hi,
As someone who has a moderate amount of interaction with the build
system, I just want to say that moz.build files are a real pleasure to
work with, and *so* much nicer than Makefiles.
Things I particularly like include...
- Having the declarative stuff (inputs and outputs) separate from the
On Tue, Jul 12, 2016 at 2:27 AM, Jonathan Griffin wrote:
>
> 2 - people sometimes push to try from bad heads (like a mozilla-inbound push
> that will eventually get backed out)
>
> For 2, making sure you push to try only from the current tip of m-c will
> avoid this problem, or using MozReview's a
Docs might be useful, but they won't cover all cases. Sometimes you
get certain failures that only show up for a short time due to infra
weirdness. I often find myself asking on IRC if a particular kind of
failure is known, and often the answer is a variation on "yes, that's
just been happening rec
Can you buy chips with that many cores, or are these instances
aggregations of multiple chips?
Nick
On Fri, Aug 5, 2016 at 9:01 AM, Gregory Szorc wrote:
> I've been playing around with various Amazon EC2 instances lately. They
> offer a x1.32xlarge instance that features 128 vCPUs. So I did what
Congratulations, Nathan!
It's not unusual for module peers to be experts in only part of a module,
so that part sounds fine to me.
Nick
On Tue, Dec 13, 2016 at 6:17 AM, Gregory Szorc wrote:
> Nathan Froyd has been doing a lot of great work at the periphery of the
> build system for years, espe
tools/rewriting/ThirdPartyPaths.txt in the repo is another list of
third-party code.
Nick
On Wed, Jan 11, 2017 at 4:53 AM, Ted Mielczarek wrote:
> On Tue, Jan 10, 2017, at 08:27 AM, polly.s...@gmail.com wrote:
> > Thanks Ted! Sorry it's taken me so long to acknowledge your nice
> > introduction
There are multiple kinds of docs. One group that I've done a lot of work on
is the collection of pages under
https://developer.mozilla.org/en-US/docs/Mozilla/Performance. I'm not sure
if in-tree would be better for those or not, but they're certainly in a
different category to API docs, for example
This is excellent news.
Relatedly, I want to particularly say that I think moz.build files are
great. The syntax and semantics are very clear. They're easy to modify.
They handle both simple cases and complex cases well. They pretty much
never get in the way, which is exactly what a developer want
Thank you for working on this, jgilbert.
I tried to take advantage of C++14's relaxed constexpr for bug 1451278, but
I'm getting one test job failure on automation, visible here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=bcd8e01989d987268cfb6beb7f86e948eae3730d&selectedJob=172004924
> * You must be using an in-tree OBJDIR.
Does it handle multiple in-tree objdirs? E.g. I have d64 (debug), o64
(opt), etc.
Nick
On Tue, Aug 7, 2018 at 11:18 PM, Jonathan Watt wrote:
> This is great! A big thank you to all the folks who have worked for so
> long to
> get us to this stage. I'
11 matches
Mail list logo
