On 11/20/13, 1:15 PM, Tim Abraldes wrote:
I would favour a whiteboard tag or keyword on the bug tracking the build
failure. It should be easy enough to create a query for all open bugs
with this tag. Usually you want to get to the bug anyway for the latest
workaround and/or info on what to back
On 11/20/13, 2:02 PM, Zack Weinberg wrote:
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote:
I wouldn't go all the way to that extreme. The list of broken system
headers is unfortunately quite large, and we already have lots of this
pattern in the tree:
#ifdef MyFunction
// screw you,
On 11/19/2013 10:08 PM, Gregory Szorc wrote:
On 11/18/13, 11:15 PM, Gregory Szorc wrote:
Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
build times on my 2013 2.6 GHz
On 11/14/13, 2:49 PM, Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds work is
by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build
files. With that, the build
I like where you are coming from.
However, if we know what build bustage is known, it should be codified
in the tree and the build should abort or you should see a giant
warning. If we put this information anywhere else, I fear it will become
out of date very quickly or filled with content
On 11/18/13, 11:15 PM, Gregory Szorc wrote:
Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
build times on my 2013 2.6 GHz MacBook Pro were as follows:
Wall 11:13 (673)
User
Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
build times on my 2013 2.6 GHz MacBook Pro were as follows:
Wall 11:13 (673)
User 69:55 (4195)
Sys6:04 (364)
Total 75:59
:
https://gps.pastebin.mozilla.org/3620075
https://gps.pastebin.mozilla.org/3620086
On 11/14/13, 11:43 PM, Gregory Szorc wrote:
C++ developers,
Over 90% of the CPU time required to build the tree is spent compiling
or linking C/C++. So, anything we can do to make that faster will make
the overall
On 11/15/13, 12:26 PM, Terrence Cole wrote:
The problem this mess is solving, at least in the GC, is that gecko
needs to be able to inline barriers, UnmarkGray, and misc other stuff.
Whenever we accidentally out-of-line anything in these paths we see a
tremendous slowdown on dromaeo_dom and
I think providing a non-public API to modify the run-time behavior of
code, using gtest's FRIEND_TEST macro to give tests the ability to
modify private class members, or using Google's googlemock C++ mocking
framework are all better than littering #ifdefs like this throughout the
code.
On 11/5/13, 2:00 AM, Neil wrote:
Gijs Kruitbosch wrote:
I don't have all my patches applied all the time. If I work on
something, leave it for 2 weeks, and qpush it again, I usually get to
do the fix all the .rej dance.
That's an interesting use case. If changeset evolution replaces mq you
On 10/30/13, 2:55 AM, Neil wrote:
Gregory Szorc wrote:
OK, so you run make, make.py, or mozmake to build the tree. Do you
ever perform partial tree builds? That is: |make -C dom| or |cd dom;
make|. If so, you may be impacted by a recent change to the build system.
If you attempt to perform
If you use |mach build| to build the tree, stop reading: this post does
not apply to you.
OK, so you run make, make.py, or mozmake to build the tree. Do you ever
perform partial tree builds? That is: |make -C dom| or |cd dom; make|.
If so, you may be impacted by a recent change to the build
On 10/21/2013 9:47 AM, Avi Hal wrote:
On Wednesday, October 16, 2013 4:43:03 PM UTC+3, Mike Hommey wrote:
...
- Build with:
./mach build
After you built once, you can do edit-compile-edit-compile cycles with:
./mach build binaries
So what's the difference between |./mach
On the Q4 goals list. Bug 929147.
On 10/21/2013 2:47 PM, David Rajchenbach-Teller wrote:
Wouldn't it be interesting to also have a
./mach build frontend
that repackages XUL and js code?
On 10/21/13 6:53 PM, Gregory Szorc wrote:
So what's the difference between |./mach build
The proposed quarterly goals for the build system have been posted to
dev.builds and will be discussed at a meeting in ~24 hours. If you are
interested in influencing what build work happens this quarter, now is
the opportunity to get engaged.
Please keep discussion unified on dev.builds.
Possible crazy idea: do we actively track and send tree management
notices when package or binary size changes? This seems like something
we'd want to cover under the perf regressions get backed out or need
approval policy. It may also help identify build system regressions and
compiler
On 10/8/13 1:16 PM, David Rajchenbach-Teller wrote:
A (not very) long time ago, our extension model was based on XPCOM – if
you didn't like a component, you could just replace it in an add-on.
These days, we have shifted to providing JavaScript modules and
suggesting JavaScript add-ons.
Now, by
On 10/8/13 9:14 PM, Dave Townsend wrote:
I was asked to clarify what I meant by my two examples so here are some
snippets of code that illustrate it. This is forcibly async but you get the
point I hope. If you want to add three numbers you can define:
function add3(foo, bar, baz) {
return
Would you like to make the tree build faster? Of course you do! Read on
to find out how you can help.
As announced a few days ago [1], mochitest tests are now declared in
.ini manifest files [2] instead of Makefile.in. There are a number of
advantages to declaring tests this way. One reason
8.8s here!
~1.5 is startup and checking the build backend is up to date (lots of stats)
~1.5s is processing install manifests.
Rest is make processing.
The fact that your machine spent ~20s doing install manifest processing
tells me:
a) Your directory tree wasn't cached (try running again)
On 10/1/13 10:43 AM, Gregory Szorc wrote:
On 10/1/13 10:26 AM, Karl Tomlinson wrote:
Gregory Szorc writes:
Just landed in inbound is a mass conversion of mochitests to use
manifests.
When adding a new test, the process used to be:
1. add new file path/to/test/directory/new-file
2. add new
/Build_Documentation/test_manifests.html.
On 9/24/13 9:23 PM, Gregory Szorc wrote:
Just landed in inbound and bound to stick sooner or later are some
changes to how tests are integrated with the build system.
* The per-directory xpcshell make targets have been removed. Use mach
(preferred
Just landed in inbound and bound to stick sooner or later are some
changes to how tests are integrated with the build system.
* The per-directory xpcshell make targets have been removed. Use mach
(preferred) or TEST_PATH=... make xpcshell-tests top-level make target.
* xpcshell.ini files are
On 9/20/13 2:50 PM, Botond Ballo wrote:
Hi everyone,
The C++ Standards Committee is meeting in Chicago next week. Their focus will
be on C++14, the upcoming version of the C++ standard, as well as some
Technical Specifications (specifications for features intended to be
standardized but not
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
On Sep 22, 2013, at 18:20, Mark Hammond mhamm...@skippinet.com.au wrote:
On 23/09/2013 11:04 AM, Gregory Szorc wrote:
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
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 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
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
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
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:
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
$ 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/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
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/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
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
(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
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
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
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
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
, 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
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
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
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
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?
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
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
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
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
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/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/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/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 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
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
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
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
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/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/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/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/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/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/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
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 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
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
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.
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,
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
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 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
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
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
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
401 - 500 of 526 matches
Mail list logo
