The marionette-harness tests should be runnable even without an objdir, however the
marionette moz.build file doesn't get included without a build via the DIRS variable.
This change gets around that issue by specifically including the marionette-harness
manifest from the root moz.build, though maybe it would be better to always process
the testing/marionette/moz.build file, and move things that need to behind an
"if CONFIG['MOZ_BUILD_APP']" condition?
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : 153f39b2024e4ae19e97537c045f3929f129e66f
The marionette-harness tests should be runnable even without an objdir, however the
marionette moz.build file doesn't get included without a build via the DIRS variable.
This change gets around that issue by specifically including the marionette-harness
manifest from the root moz.build, though maybe it would be better to always process
the testing/marionette/moz.build file, and move things that need to behind an
"if CONFIG['MOZ_BUILD_APP']" condition?
MozReview-Commit-ID: Ata99evHxbd
--HG--
extra : rebase_source : c4184d0cf38c820443aeb5cd63985cd0ec0d649e
By including the mozbase's moz.build directly in the root moz.build, we are making sure that
mozbase unittests will be found even if there is no build/objdir. This will be useful when
running mozbase tests in their own taskcluster task.
MozReview-Commit-ID: DqqY09I3JBC
--HG--
extra : rebase_source : 46c2386e3a6fc2106f8277fde1363e4c28457d0f
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
The `taskgraph` package generates TaskCluster task graphs based on collections
of task "kinds". Initially, there is only one kind, the "legacy" kind, which
reads the YAML files from `testing/taskcluster/tasks` to generate the task
graph.
Try syntax is implemented by filtering the tasks in the taskgraph after it has
been created, then extending the result to include any prerequisite tasks.
A collection of `mach taskgraph` subcommands are provided for developers to
extend or debug the task-graph generation process.
MozReview-Commit-ID: 1TJCns4XxZ8
--HG--
rename : testing/taskcluster/docs/index.rst => taskcluster/docs/index.rst
extra : rebase_source : 7b9125281d66044db9bd8e4a1fade16136f384b9
extra : histedit_source : 47640d27080acda0279270babbcf33f5badb0d1c
It is possible to hook up in-tree documentation to Sphinx. Convert the
one-off README.md to ReStructuredText and add it to the Sphinx docs.
I added a moz.build file under testing/ because I don't think it is
appropriate for the Sphinx directive to live in the root moz.build file.
MozReview-Commit-ID: 90tCb7mA63C
--HG--
rename : testing/taskcluster/README.md => testing/taskcluster/docs/index.rst
extra : rebase_source : 9312445aa17a1a2b03195a4f18442f8a8a0d8fe9
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
Both these files, are, after all, define files, like other CONFIGURE_DEFINE_FILES.
They only happen to have a special requirement for an expansion for all defines,
which doesn't need to happen through traditional preprocessing.
This change adds consistency in how configure-related headers are being handled.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
JS_STANDALONE builds don't need everything in mozglue; have mozglue omit the
unneeded code for such builds.
Since the SpiderMonkey binaries are now more like the other Gecko binaries, we
can remove some special cases for JS_STANDALONE in GeckoSharedLibrary,
GeckoProgram, etc. All Gecko binaries now use mozglue, which contains mfbt, so
we no longer need mention mfbt explicitly.
Add a property to the getBuildConfiguration testing function's result that
indicates whether we're using jemalloc or not.
Include the newly necessary source directories in the SpiderMonkey source
package.
We want the ability to read data from any moz.build file without needing
a full build configuration (running configure). This will enable tools
to consume metadata by merely having a copy of the source code and
nothing more.
This commit creates the EmptyConfig object. It is a config object that -
as its name implies - is empty. It will be used for reading moz.build
files in "no config" mode.
Many moz.build files make assumptions that variables in CONFIG are
defined and that they are strings. We create the EmptyValue type that
behaves like an empty unicode string. Since moz.build files also do some
type checking, we carve an exemption for EmptyValue, just like we do for
None.
We add a test to verify that reading moz.build files in "no config" mode
works. This required some minor changes to existing moz.build files to
make them work in the new execution mode.
--HG--
extra : rebase_source : f701417f83dfa4e196e39182f8d0a6fea46c6fbb
extra : source : af07351bf2d6e85293ae3edf0fe4ae6cbc0ce246
Before, we would run configure in both top-level and js/src, and both
configures would traverse their own set of moz.builds, without actual
knowledge about the other. With this change, both configures still run,
but only top-level traverses moz.build files, and uses js/src's
config.status when traversing its moz.build files. This allows a better
sharing of information between both build systems and the removal of many
hacks.
This also moves running libffi and icu configure to top-level.
Standalone js builds still have their own configure doing moz.build traversal,
as before.
--HG--
rename : config/autoconf.mk.in => config/autoconf-js.mk.in
rename : config/emptyvars.mk.in => config/emptyvars-js.mk.in