Ever since Sphinx variable reading operates at the AST level (bug
1071012), we don't technically need a fully configured environment in
order to generate the documentation!
This patch stubs out the config environment object with a fake one that
provides the only needed context to generate the Sphinx docs. This
allows us to build the Sphinx docs on a fresh clone of the tree with no
configure and with no object directory.
--HG--
extra : rebase_source : f44513f01706391a5932a20c1437fcc8697611cd
Read the Docs has a lovely Sphinx theme that beats the pants off the
built-in and default theme. And since it looks like MDN's Sphinx theme
is dead in the water, this gets us a nice UI win until the MDN theme
comes back from the dead.
--HG--
extra : rebase_source : b4f92cf8263843d3118a85a7d9b59b98d5dd0613
requirements.txt isn't being used by the documentation infrastructure.
We nuke it.
--HG--
extra : rebase_source : d53ee5c329790d0ed7d75d6d9f451269dda6c485
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This adds arguments for the paths to jprof, the program being profiled,
and the jprof profile itself, so I don't need to modify my local copy of
split-profile.pl to fix those.
DONTBUILD
--HG--
extra : transplant_source : %97%D5%A6%1C%A86%5E%AC%F7%FB%A7%8D%B0L%1D%17%FDK%EA%9F
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.
