The in-tree Sphinx docs have been broken since bug 1041941 because
processing moz.build files outside their context doesn't work.
Specifically, templates aren't loaded (because this information usually
comes from a parent moz.build file). A new execution mode is needed.
I tried to implement a proper execution mode. However, I kept running
into walls. While we should strive for a proper execution mode, this can
be a follow-up, tracked in bug 1058359.
This patch implements extraction of Sphinx variables from ast walking.
It is extremely low-level and definitely a one-off. But it solves the
problem at hand: |mach build-docs| will work after this patch is
applied.
--HG--
extra : rebase_source : abd0a91a3efb24d3adfa19f4cd281ce5fd6d0915
extra : amend_source : c1b4f79224bab55e65a8c2b0f3103475281416c1
The reason to use '+' prefixing was to distinguish between options to the
mach command itself, and options that are passed down to whatever the
command does (like mach run passing down args to the built application).
That makes things unnecessarily awkward, and quite non-standard.
Instead, use standard '-' prefixing, and pass all the unknown arguments
down. If there is overlap between the known arguments and arguments supported
by the underlying tool (like -remote when using mach run), it is possible to
use '--' to mark all following arguments as being targetted at the underlying
tool.
For instance:
mach run -- -remote something
would run
firefox -remote something
while
mach run -remote something
would run
firefox something
As allow_all_arguments is redundant with the presence of a argparse.REMAINDER
CommandArgument, allow_all_arguments is removed. The only mach command with a
argparse.REMAINDER CommandArgument without allow_all_arguments was "mach dmd",
and it did so because it didn't want to use '+' prefixes.
By default, breakpad uses the build-id section for ids, if it isn't
found, it uses the .text section. On the later case, the stripped
libraries will have different ids from their non-stripped counterparts.
See Bug 1062459 for details.
This is needed to avoid regressions relative to the perl version because
the perl version failed, due to a missing /, to properly examine two of
the paths, one of which often yields the same filename as the original
file (but whose CRC will fail).
I've tested that this CRC calculation succeeds in cases where it should
succeed.
The observed CRC check failures (so far) on my Ubuntu 14.04 system are
the following links:
/lib/x86_64-linux-gnu/libc.so.6 -> /lib/x86_64-linux-gnu/libc-2.19.so
/lib/x86_64-linux-gnu/libpthread.so.0 -> /lib/x86_64-linux-gnu/libpthread-2.19.so
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 -> /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 -> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23
which succeed on a later possibility in /usr/lib/debug/. But optimizing
to check f != file before checking the CRC wouldn't help because of the
naming differences due to symlinks, so I didn't bother. If we ever want
to optimize away the time doing the CRC checks for these failures, we
could do so by checking if the files are the same path *after* resolving
symlinks.
DONTBUILD
Straight assignments to HierarchicalStringList, which we'll change
EXTRA_JS_MODULES to in a later patch, don't work. This change, in
addition to making things work as expected later on, also is more
consistent with existing practice.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
bzpost is an efficiency win for everyone.
firefox tree is mostly useful for people doing head/bookmark-based
development.
Both extensions can yield massive productivity wins. They should be
advertised.
DONTBUILD (NPOTB) on a CLOSED TREE
--HG--
extra : rebase_source : ab72d3afd6ab244bfdbdb2dda5e0b45c9d8f782e
extra : amend_source : 91ec7523a4631c7519efd3b6cd425cff00bd0569
We want to make it turnkey for people to use reviewboard. So, we add
reviewboard and related functionality to |mach mercurial-setup|.
Since the reviewboard extension only works in Mercurial 3.0 and newer,
we add some version detection for the Mercurial version. This should
have been done months ago. We now have it.
I also took the opportunity to inform |mach bootstrap| that Mercurial
2.x is no longer modern.
I also updated the messaging around mq to encourage fewer new users to
use it. You may find this controversial. People can always ignore the
message.
Finally, I also added a histedit prompt to the mix, since a lot of
people don't know about that and many find it useful.
I could have broken this into multiple patches. Meh.
--HG--
extra : rebase_source : d33f8abcabb6ad6511c2f9e202283d43613fafc4
extra : amend_source : 3a56bc4d49ee6200cbdd0e87b4f28489518fee79
The -*- file variable lines -*- establish per-file settings that Emacs will
pick up. This patch makes the following changes to those lines (and touches
nothing else):
- Never set the buffer's mode.
Years ago, Emacs did not have a good JavaScript mode, so it made sense
to use Java or C++ mode in .js files. However, Emacs has had js-mode for
years now; it's perfectly serviceable, and is available and enabled by
default in all major Emacs packagings.
Selecting a mode in the -*- file variable line -*- is almost always the
wrong thing to do anyway. It overrides Emacs's default choice, which is
(now) reasonable; and even worse, it overrides settings the user might
have made in their '.emacs' file for that file extension. It's only
useful when there's something specific about that particular file that
makes a particular mode appropriate.
- Correctly propagate settings that establish the correct indentation
level for this file: c-basic-offset and js2-basic-offset should be
js-indent-level. Whatever value they're given should be preserved;
different parts of our tree use different indentation styles.
- We don't use tabs in Mozilla JS code. Always set indent-tabs-mode: nil.
Remove tab-width: settings, at least in files that don't contain tab
characters.
- Remove js2-mode settings that belong in the user's .emacs file, like
js2-skip-preprocessor-directives.
