The build system being what it currently is, there are various cases where one
wants something explicit, rather than the current autodetection.
For instance, one may want to run
make -C $objdir chrome
instead of
make -C $objdir/chrome
that mach build chrome currently invokes.
There are several such usecases that mach's autodetection makes harder, and
it's sometimes awkward when telling people, to debug their issues, to run
make -C objdir something
and hear back that objdir doesn't exist or something along those lines,
because they took "objdir" literally.
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.
It's not entirely clear passing down all the metadata makes sense. On the
other hand, when creating the template execution sandbox, passing down
exports does assign the value for the exported variable in that execution
context. When that context is merged with the caller sandbox context, the
exported variable is reassigned, even if the value is not modified. Then,
if the caller sandbox itself reassigns the exported variable, it fails
because calling a template already did it once, unexpectedly.
Not passing down exported variables makes the template execution sandbox
never set those exported variables, so that they are not merged back. The
caller sandbox can then properly reassign the exported variable.
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.
