On 8/15/12 11:10 PM, Mike Hommey wrote:
Something I noticed recently is that we spend more than 5 minutes (!)
during windows clobber builds to do the clobber (rm -rf). All try builds
are clobbers. A lot of time is wasted on mercurial cloning, too.
What is interesting is that the corresponding
tl;dr We're proposing moving away from Makefile's as the sole source of
the build system definition. This will lead to faster build times.
Bikeshedding^wFeedback on the file format is requested.
The existing build system is defined by Makefile.in's scattered around
the source tree (typically
On 8/21/2012 6:12 PM, xunxun wrote:
于 2012/8/22 7:36, Gregory Szorc 写道:
Up until now, the focus has been on making Makefile.in's themselves
generic and data-driven [1]. We would use pymake's API to parse,
load, and extract data from Makefile.in's to construct the build
definition. In the long
I just landed a change to how the Python virtualenv is populated during
configure. The short story is there are no more .egg-info/ directories
created in the source directory as part of virtualenv population.
These directories are no longer ignored by .hgignore and .gitignore, so
the next
On 9/3/2012 6:45 PM, qheaden wrote:
On Sunday, September 2, 2012 5:15:40 PM UTC-4, Gregory Szorc wrote:
A decision has been made: we will be using Python files executing in a
sandboxed environment (using the technique that Hanno posted).
Supporting this decision are Ted (build system owner
On 9/4/2012 11:09 PM, Nicholas Nethercote wrote:
On Tue, Sep 4, 2012 at 9:39 PM, Mike Hommey m...@glandium.org wrote:
On the other hand, the ccache miss rate is pretty high, at least it is
for me, so in the end, ccache might not be a win at all.
That's what I've found, for my compiling
The subject of which version of Python to require to build the tree came
up in bug 784841.
We currently require Python = 2.5 but 3 to build the tree. The main
reason for the 2.5 requirement is the Linux build slaves still run
Python 2.5. Those of us who code Python for the tree have long
I like the idea. However, we have a big obstacle: MDN.
Many believe that MDN should be where user-facing API documentation
lives. MDN certainly has a better user experience than foraging around
mozilla-central (especially if you are just a casual developer). If I'm
a casual extensions
The next time you pull mozilla-central, you'll find a new tool in the
root directory: mach
$ ./mach build
0.09 /usr/bin/make -f client.mk -j8 -s
0.25 Adding client.mk options from /Users/gps/src/services-central/.mozconfig:
0.25 MOZ_OBJDIR=$(TOPSRCDIR)/objdir
0.25 MOZ_MAKE_FLAGS=-j9
a...@aryeh.name:
On Thu, Sep 27, 2012 at 6:08 PM, Gregory Szorc g...@mozilla.com wrote:
I actually held out on you with the initial landing of mach: there is more
advanced tree building code in the pipes, complete with progress indicators.
However, getting it reviewed is a challenge because we want
On 10/3/12 5:22 PM, Honza Bambas wrote:
I just hit
some compilation error caused by some recent patch in conjunction with
my build config and mach has just failed with a python trace back:
There was no warning log as well. I was a bit hoping that mach would
help with this (tracking build error
We now have a tool in mozilla-central that has a much better UX for
running tests (mach). It's not perfect yet, but it's getting there
(please write patches!).
The build peers (or at least a few of us) really don't like the make
targets to run tests because they are awkward, both to maintain
On 10/8/12 12:17 PM, L. David Baron wrote: On Monday 2012-10-08 12:05
Updating the documentation on how to run the tests (which is spread
across a bunch of places) is extremely important. You should also
expect to get more feedback once that happens.
Well, one of the benefits of mach is you
On 10/8/12 12:34 PM, Jesper Kristensen wrote:
Before you deprecate the make targets, it would be nice if mach actually
works and there is documentation for it.
For documentation, one of the fundamental features of mach is it should
be self-documenting. You should be able to run |mach help|
On 10/8/12 8:10 PM, Zack Weinberg wrote:
When I run tests locally I do so by hand, because I invariably require
more precise control over how the test suite is operating than the make
targets allow. (I have occasionally even needed to bypass runtest.py.)
I expect mach will have the same
On 10/26/12 2:48 AM, Gervase Markham wrote:
On 25/10/12 14:48, Henrik Skupin wrote:
When I started to work on tests for WebRTC and WebAPI lately I have
noticed that there are no clear specifications where tests have to be
added. Some are located in a tests subdirectory (like
On 10/29/12 7:17 PM, Ehsan Akhgari wrote:
On 2012-10-29 9:11 PM, Gregory Szorc wrote:
On 10/29/12 5:52 PM, Robert O'Callahan wrote:
On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote
n.netherc...@gmail.com
wrote:
#pragma once does have one drawback (other than being non-standard
On 11/2/12 1:08 AM, Ms2ger wrote:
On 11/02/2012 01:47 AM, Dave Mandelin wrote:
First, I want to try to pour some gasoline on the dying embers and
suggest that perhaps we should totally rearrange everything. As a
developer user of our testing systems, I always found it incredibly
irritating that
I have scheduled a brown bag on the future of Firefox's build system. It
is tentatively scheduled for November 29 at noon Mountain View time (I
would present earlier but MozCamp and US Thanksgiving are conspiring to
prevent many from attending).
My primary goal of the talk is to spread
On 11/9/12 10:28 AM, Kyle Huey wrote:
I reviewed a patch today that had:
using namespace mozilla;
using namespace dom;
The intent is to pull in the contents of both the mozilla and mozilla::dom
namespaces, but this is only clear if you know that there is no top-level
dom namespace. In the
On 11/25/12 7:29 PM, L. David Baron wrote:
On Monday 2012-11-26 04:21 +0100, Robert Kaiser wrote:
Justin Dolske schrieb:
I think we should consider jettisoning/rewriting that part of the
policy. It doesn't match what we've been doing in reality(*)
Yes, that's why we almost f***ed up 17.0 and
On 11/27/12 2:55 PM, Chris Peterson wrote:
On 11/27/12 2:35 PM, Gregory Szorc wrote:
I feel the build system should be as fast as possible by default - no
user action necessary. If you find that -j == # cores isn't providing
the fastest builds possible, please present your data and we'll change
On 11/27/12 5:02 PM, Nicholas Nethercote wrote:
On Tue, Nov 27, 2012 at 2:35 PM, Gregory Szorc g...@mozilla.com wrote:
If you have |-s|, if you build with |./mach build|, it uses silent mode by
default, so again, you don't need MOZ_MAKE_FLAGS.
What about --no-print-directory? I specify
this transition effectively
means we can stop supporting 2.6 and below everywhere in the tree as
soon as 2.7 is deployed everywhere.
If there are any objections, please voice them now.
Gregory
On 10/19/2012 11:30 AM, Gregory Szorc wrote:
Inbound now requires Python 2.6:
https://hg.mozilla.org
On 12/1/2012 4:28 PM, Neil wrote:
On a side note, what can we do about checking for unusually verbose or
inefficient constructs? Examples:
We could create a compiler plugin that examines the AST for known
badness. See bug 733873.
___
dev-platform
I originally sent this as a reply to the Minimum Required Python
Version thread. Per request, I'm reposting as a new topic so it doesn't
go unnoticed. We will also likely discuss this at the engineering
meeting tomorrow. SeaMonkey has also requested an additional week to
switch things over, so
On 1/15/13 1:11 PM, Ehsan Akhgari wrote:
Hi all,
Currently, DONTBUILD only takes affect if it's set on the tip of the
changesets that you push. This can cause problems when merging between
different trees if the target tree is a full subset of the origin tree
(i.e., fast-forward merges in git
I'm writing to the Platform list as a developer that maintains a
significant amount of JavaScript for Firefox. Much of the JavaScript I
maintain is for large backend features, such as Sync and Firefox Health
Report. These features are thousands of lines of code (mostly
JavaScript) and interact
This thread is reminding me why we have an in-tree system bootstrapper
tool (/python/mozboot) to effortlessly configure an optimal development
environment. If running that does not install what you need, please file
a Core :: Build Config bug and consider contributing a patch to make it
do
On 2/22/2013 5:41 PM, Brian Smith wrote:
bernhardr...@gmail.com wrote:
i'm willing to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=836602
Summary: The rest api should not send cookies and thus now uses the
LOAD_ANONYMOUS flag. But this flag also denies (client side)
authentication like
On 3/4/13 5:15 AM, Jim Mathies wrote:
For metrofx we’ve been working on getting omtc and apzc running in the browser.
One of the things we need to be able to do is run performance tests that tell
us whether or not the work we’re doing is having a positive effect on perf. We
currently don’t
On 3/6/13 9:07 AM, Kyle Huey wrote:
Gecko reviewers should be enforcing this.
Static analysis should be helping to enforce this (and numerous other
conventions).
Bugs 733873 and 767563 (possibly dupes) are open to track implementing a
Clang plugin to perform analysis of our source and
Following the initial transition to moz.build files a few weeks ago,
we're now ready to start porting more variables to moz.build files. We
decided the strategy will be to largely cut and paste variables from
Makefile.in to moz.build files and then follow up with improvements to
the schema,
Our build config has a number of areas where metadata is centrally
defined and a module or component's configuration is fragmented in the
source tree. Here are some examples:
1) Preferences and all.js. We currently define most of the default
preferences in /modules/libpref/src/init/all.js.
On 3/19/13 11:57 AM, jmaher wrote:
The consensus is the master manifest solution is not of interest, are there
proposals and plans to remove:
testing/xpcshell/xpcshell.ini
testing/crashtest/crashtests.list
layout/reftest/reftests.list
This thread seems as though it is focusing on one of the 3
On 3/27/13 2:03 PM, Justin Lebar wrote:
Since we believe if we go through with this it would be the first time we use a
true subrepository system for a component
used in mozilla-central, we'd very much appreciate any thoughts or feedback
people might have on the idea.
Have you thought about
The CLOBBER file landed a few months ago to help us detect and prevent
known build bustage. Since then, a lot of people (myself included) have
pushed to trees not knowing they needed to force a clobber first,
causing burnage. Others have been frustrated that |hg pull -u mach
build| followed by a
On 3/29/2013 11:29 AM, Emanuel Hoogeveen wrote:
How are things looking with regards to using hg purge (bug 851270)?
As far as I'm concerned, that's in RelEng's court. I hope they solve it
soon because not using hg purge is adding huge delays (15+ minutes for
some Windows builds) for all clobber
On 3/29/2013 5:32 PM, Neil wrote:
Gregory Szorc wrote:
* Your mozconfig contains |mk_add_options NO_AUTOCLOBBER=1| or your
environment contains NO_AUTOCLOBBER.
Exactly what happens in this case, does it still fail in configure?
(The old failure mode was not detectable by client.mk so you
On 4/1/2013 11:00 AM, Jeff Hammel wrote:
On 03/29/2013 06:01 PM, Gregory Szorc wrote:
snip/
I highly recommend against defining MOZ_OBJDIR in terms of relative
paths. You're implicitly creating a dependency on cwd. This is handy
in a few use cases but it's a giant foot gun. Instead, do
On 4/1/13 6:04 AM, Ryan VanderMeulen wrote:
For 4 months now, we've been dealing with intermittent segfaults in gcc
during compilation, most often in IonBuilder.cpp. We've been tracking
these failures in bug 820796. Given that this is pointing to a compiler
bug, it seems unlikely that we're
On 4/3/13 4:11 PM, Gregory Szorc wrote:
I pulled the raw builder logs from
https://secure.pub.build.mozilla.org/builddata/buildjson/ and assembled
a tab-separated file of all the builds for 2013-03-17 through 2013-03-23:
https://people.mozilla.com/~gszorc/builds-20130317-20130323.txt.bz2
On 4/4/13 8:07 AM, Kartikaya Gupta wrote:
On 13-04-03 19:49 , Jesse Ruderman wrote:
+1.
But can we do this with rebased changesets instead of trivial merge
changesets? While the core of hg can handle merges, pretty much none of
the tools we rely on for understanding history (hg {log, grep,
On 4/10/2013 2:42 PM, Benoit Girard wrote:
With the fix to bug 844288 gtest will also need their own directory. I was
planning on allowing users to use component/tests folder for their tests
but to go in line with this upcoming change I'll update my patches and
suggest that anyone who adds
On 4/10/2013 1:38 PM, Jason Smith wrote:
Hi Everyone,
Right now, when a landing occurs, my understanding is that we're
typically setting the target milestone field to what Firefox release
the code lands on if it lands on trunk. If a patch is uplifted, then
the status flag is set
Mercurial and Git both support the ability to attach arbitrary key-value
string data to commits. There is an abundance of awesomeness that could
be realized if we started storing [machine readable] information inside
our commits (not inside the commit messages). Here are some examples:
* Who the
On 4/11/2013 1:57 AM, Neil wrote:
Gregory Szorc wrote:
We should eventually be able to get to a state where there are no
moz.build/Makefile.in files in test directories. Well, at least for
test suites using manifests to define test files (xpcshell,
mochitest, reftest, possibly others).
Do
On 4/16/2013 10:15 PM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where lists are sometimes unordered and it's
hard to find items and know
On 4/17/13 2:37 PM, Robert O'Callahan wrote:
On Thu, Apr 18, 2013 at 3:40 AM, Ms2ger ms2...@gmail.com wrote:
On 04/17/2013 07:15 AM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system
think we should either opt in to auto-clobbering or prompt to
clobber by default and allow users to opt out of the prompt.
On Thu, Apr 18, 2013 at 12:18 AM, Ralph Giles gi...@mozilla.com wrote:
On 13-04-17 12:36 PM, Gregory Szorc wrote:
It /could/, sure. However, I consider auto clobbering a core
On 4/18/13 1:03 PM, Lukas Blakk wrote:
Hello,
I'm following up on an action from our Firefox 20 Post-Mortem where it was
discussed that it would be helpful to have a way to pref on a set of features
that want to be in early Beta builds to garner feedback and audience reach but
should not
PM, Gregory Szorc wrote:
I agree that we should consider a compromise regarding the UI/UX of
auto clobber. I have filed bug 863091.
I would like to say that I view the object directory as a cache of the
output of the build system. Since it's a cache, cache rules apply and
data may disappear
I'd like to start a discussion about the state of storage in Gecko.
Currently when you are writing a feature that needs to store data, you
have roughly 3 choices:
1) Preferences
2) SQLite
3) Manual file I/O
Preferences are arguably the easiest. However, they have a number of
setbacks:
a) Poor
On 4/26/2013 12:10 PM, Benjamin Smedberg wrote:
On 4/26/2013 2:50 PM, Gavin Sharp wrote:
On Fri, Apr 26, 2013 at 11:36 AM, Andreas Gal g...@mozilla.com wrote:
Preferences are as the name implies intended for preferences. There
is no sane use case for storing data in preferences. I would give
On 4/26/2013 2:06 PM, Kartikaya Gupta wrote:
On 13-04-26 11:37 , Phil Ringnalda wrote:
Unfortunately, engineering is totally indifferent to
things like having doubled the cycle time for Win debug browser-chrome
since last November.
Is there a bug filed for this? I just cranked some of the
Great post, Taras!
Per IRC conversations, we'd like to move subsequent discussion of
actions into a meeting so we can more quickly arrive at a resolution.
Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday, April 30.
That's 2200 UTC. Apologies to the European and east coast
On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote:
Specific goals:
-Offer an alternative branch for developers to push to during extended
inbound closures
-Avoid patch pile-up after inbound re-opens from a long closure
Specific non-goals:
-Reducing infrastructure load
-Changing pushing
On 5/2/2013 4:13 PM, Lawrence Mandel wrote:
- Original Message -
Great post, Taras!
Per IRC conversations, we'd like to move subsequent discussion of
actions into a meeting so we can more quickly arrive at a resolution.
Please meet in Gregory Szorc's Vidyo Room at 1400 PDT Tuesday,
On 5/3/2013 12:20 AM, Dirkjan Ochtman wrote:
On Fri, May 3, 2013 at 8:43 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
In git, the only way to have something in your history is for it to be
reachable by a ref (for example, a branch name). When you convert an hg
repo with a multi-headed
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
On 5/13/13 9:08 AM, Mike Shal wrote:
Hi all,
I'd like to reserve Wednesday morning starting at 6am PDT to close
central/inbound/birch to get the CPPSRCS moz.build conversion (bug
864774) landed and in each branch. (I tried to land it on inbound this
weekend, but it didn't go so well).
I don't
On 5/15/13 2:18 PM, Vladan Djeric wrote:
Hi all,
I recently came across a situation where it would have been useful to
control the order in which components receive the same shutdown
notification. Specifically, Telemetry writes out session data to the
profile dir during the
On 5/15/13 3:31 PM, L. David Baron wrote:
On Wednesday 2013-05-15 14:32 -0700, Gregory Szorc wrote:
I think the more compelling use case is service startup. Proper
dependencies should allow us to more intelligently start services on
demand. This should lead to lower resource utilization
As I wrote at [1] there are some scenarios where the build system and
related tools would like to store persistent state. Some uses for this
include:
* Automatically recording previous build logs, compiler warnings, and
test results.
* Holding build environments (downloaded Mercurial
On 4/16/13 10:15 PM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where lists are sometimes unordered and it's
hard to find items and know
Bug 828317 just landed and the build system now enforces using pymake
(not GNU make) to build on Windows. If you attempt to use GNU make, it
will complain loudly and tell you how to invoke pymake.
The short version of history is that pymake is faster and more stable
than GNU make on Windows
for RelEng
to worry about).
On 5/16/13 12:53 PM, Gregory Szorc wrote:
As I wrote at [1] there are some scenarios where the build system and
related tools would like to store persistent state. Some uses for this
include:
* Automatically recording previous build logs, compiler warnings, and
test results
On 5/28/13 7:28 AM, xunxun wrote:
于 2012/9/27 9:12, Gregory Szorc 写道:
The next time you pull mozilla-central, you'll find a new tool in the
root directory: mach
$ ./mach build
Well, when I try mach build on Win8 x64 and use VC2010 Chinese Edition
compiler, its output information (Chinese
On 6/18/13 9:05 PM, Anthony Jones wrote:
On 19/06/13 16:02, Robert O'Callahan wrote:
I believe that in Webkit you're not supposed to call new directly.
Instead you call a static create method that returns the equivalent of
already_AddRefed.
Do they have a lint checker we can use for that?
tl;dr You may experience a change in behavior in build performance
In bug 884587, we just changed how file purging occurs during builds.
Due to historical reasons (notably bad build dependencies and to prevent
old files from leaking into the distribution package), we wipe out large
parts of
Traditionally, it's been very difficult for the build peers to keep on
top of changes in the build config because changes are occurring on bug
components we don't follow, are touching files all over the tree, and
because build peers aren't always asked for review.
The potential for sneaking
On 7/18/13 6:33 AM, Byron Jones wrote:
an update was pushed to bugzilla.mozilla.org today which allows us to
provide a list of suggestions for the review flag (bug 804708).
this list is on a per-product or per-component basis, with the product's
suggestions being used in the absence of a
, please
don't hesitate to loudly complain.
[1] https://wiki.mozilla.org/Build_config
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=898089
On 7/17/13 5:00 PM, Gregory Szorc wrote:
Traditionally, it's been very difficult for the build peers to keep on
top of changes in the build config because
in experimenting to see if things are
possible. If they are, I'll refine over time.
Let me know if you run into any issues or have suggestions for improvements.
Gregory
On 7/22/13 11:03 AM, Gregory Szorc wrote:
Do you use Mercurial to interact with mozilla-central and related
repositories? I wrote
I don't particularly care for our model of a single Mercurial repository
per logical entity. I think it makes sense for things like twigs and to
some extent integration repositories - you can do your work in your own
little world without disrupting others. But for all the release
branches, I
On 7/29/13 12:49 PM, Ehsan Akhgari wrote:
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Legit concern. Probably low priority. I wanted to have a discussion on
it because I
On 7/31/13 5:59 PM, Justin Lebar wrote:
Sadly, mercurial doesn't support having multiple working directories
from a single clone, which would be useful to avoid wasting so much disk
space on .hg.
I'm not usually one to defend hg, but hg does have the |relink|
command, which gets you most of
You can now file bugs against this extension at Other Applications ::
mozext. I anticipate many awesome feature requests and embarrassing bugs.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Other%20Applicationscomponent=mozext
On 7/26/13 11:07 AM, Gregory Szorc wrote:
Since I announced
(Cross posting. Please reply to dev.builds.)
I've noticed an increase in the number of complaints about the build
system recently. I'm not surprised. Building mozilla-central has gotten
noticeably slower. More on that below. But first, a request.
Many of the complaints I've heard have been
On 8/2/13 3:38 PM, Ehsan Akhgari wrote:
Hmm. I'm not sure if the number of source files is directly correlated
to build times, but yeah there's clearly a trend here!
I concede a lines of code count would be a better indicator. I'm lazy.
# Header dependency hell
I have been playing with an
On 8/2/13 4:43 PM, Robert O'Callahan wrote:
Nathan has just made an excellent post on this topic:
https://blog.mozilla.org/nfroyd/2013/08/02/i-got-99-problems-and-compilation-time-is-one-of-them/
It would be interesting to measure the number of non-blank precompiled
lines in each build, over
Inbound now contains a patch from bug 890744 that will hopefully fix the
bad build dependencies related to WebIDLs on Windows when adding or
remove .webidl files.
Please stop touching CLOBBER when adding WebIDL files so we can see if
it works. If you notice bustage, please report it to bug 890744
On 8/15/13 2:50 PM, L. David Baron wrote:
On Thursday 2013-08-15 14:11 -0700, Gregory Szorc wrote:
I feel that having developers develop on the same toolchain as
official builds (producing bit-identical builds if possible) would
cut down on patch development costs due to reducing the frequency
On 8/20/13 7:27 AM, Ehsan Akhgari wrote:
On 2013-08-19 9:10 PM, Gregory Szorc wrote:
On 8/19/13 5:15 PM, Nicholas Nethercote wrote:
Hi,
Analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=901132 has
indicated that jsapi.h is probably responsible for more recompilation
than any other file
Now in inbound, |mach build| will record *system* resource usage during
builds. You can later view the resource usage by running |mach
resource-usage| (mach will tell you at the end of the build if you can
run this).
The goal of this feature is to help people diagnose why builds are slow
and
On 8/22/13 7:04 PM, Mark Hammond wrote:
On 21/08/2013 5:36 AM, Gregory Szorc wrote:
...
Finally, this is just a friendly reminder that if you build
mozilla-central and you don't have a machine with at least 4 *physical*
cores, 16 GB RAM, and an SSD, you should upgrade your hardware.
FTR, my
$ mach mercurial-setup
will do this for you.
On 8/27/2013 11:05 AM, Ed Morley wrote:
tl;dr: Please update your local bzexport qimportbz clones :-)
bzexport qimportbz (Mercurial extensions to allow direct patch
import/export from/to Bugzilla [1][2]) have received a number of new
On 8/30/13 7:09 AM, Eric Shepherd wrote:
This is sort-of-kind-of platform related, but only indirectly, so let me
know if there's a better place to ask this question, please.
If a web page needs to be able to display the current release version of
Gecko, is there a place we can pull that
tl;dr the tree currently allows you to run tests via make targets and
mach. The mach commands are more intuitive and easier to support going
forward, so I'm proposing we remove support for using make targets to
run tests. Please take the survey at
http://www.surveymonkey.com/s/H5LB2GF to
On 9/3/13 8:25 AM, Ehsan Akhgari wrote:
5. Is the git-mapfile generated from the conversion scrips available
somewhere? (Mine is currently available here:
Assuming it sticks, bug 896797 just landed in inbound and changes how
EXPORTS/headers are installed. This may impact your developer workflow
if you modify EXPORTS in a moz.build file to add/remove headers.
Previously, headers were installed incrementally as part of make
directory traversal.
On 9/4/13 3:04 AM, Mike Hommey wrote:
On Wed, Sep 04, 2013 at 10:57:26AM +0100, L. David Baron wrote:
The way the tier build works is that we effectively make export in all
directories of a same tier before make libs. In practice, this means
xpcom had access to every header in platform already,
This was done. My eyes are still bleeding from the review.
On 9/4/13 5:36 PM, Andreas Gal wrote:
Can you delete this boilerplate from existing makefiles if not already
done? That will prevent people from adding it since people look at
examples when adding new makefiles.
Andreas
Mike Hommey
Just landed in inbound and making its way to a tree near you is the
requirement that you use Python 2.7.3 or greater (but not Python 3) to
build the tree. If you see any issues, bug 870420 is responsible.
Previously we required Python 2.7.0 or greater. This change has been
planned and agreed to
On 9/18/2013 1:52 PM, Benjamin Smedberg wrote:
Right now our stability efforts are primarily focused on crashes.
However, as we have been very successful at reducing our crash rate,
some other stability issues which are not crashes have come to be more
prominent. Some examples:
* very slow
On 9/19/2013 4:56 PM, Nicholas Cameron wrote:
Hi, I seem to remember reading a post here about no longer exporting headers
during incremental builds, but I couldn't find it.
Anyway, if there is any way at all that we could undo that, it would be
awesome. For me the change means that
On 9/19/13 9:31 PM, Blair McBride wrote:
Ohai!
I have numerous copies of mozilla-central (and other repos) for various
purposes - spread around physical boxes and VMs. Some of them I use
regularly and update regularly, others not-regularly. I've been thinking
about the amount of time and
On 9/20/13 2:12 AM, Nicolas B. Pierron wrote:
On 09/19/2013 10:02 PM, Dave Townsend wrote:
I would expect that the total server load on hg.mozilla.org is high
enough
that whatever you do as a single person isn't going to be even a blip on
the radar so I'd expect just a hg pull with a reasonable
The mach script in the root directory of mozilla-central is a generic
command dispatching tool. Have a piece of commonly used functionality
useful to many people? Create a mach command so others can use it easily!
While mach started with commands dealing with build system interaction
and running
On Sep 22, 2013, at 16:35, Anthony Jones ajo...@mozilla.com wrote:
On 21/09/13 17:58, Robert O'Callahan wrote:
I don't think that's necessarily true on Windows. If we can find a way to
generate Visual Studio projects and use those to build, or do most of the
build, we can probably go a lot
1 - 100 of 526 matches
Mail list logo
