VS2017's directory structure for mfc is the following.
Directory of C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\vc\Tools\msvc\14.10.24629\atlmfc\lib
2016/11/21 13:57 <DIR> .
2016/11/21 13:57 <DIR> ..
2016/11/21 13:57 <DIR> arm
2016/11/21 14:00 <DIR> x64
2016/11/21 13:59 <DIR> x86
So this structure is changed, we cannot detect mfc when using VS2017.
MozReview-Commit-ID: 2ft4stYPZbe
--HG--
extra : rebase_source : c985022eb5b99f32398f1f5c1d2e274c2a4677e7
extra : amend_source : 8b94aba289397dc84d0d360991666ed5a5a8ac07
In some cases, on OSX, python's `os.path.realpath` and shell's `pwd -P`
don't agree on the case of paths on case-insensitive filesystems.
So make everyone agree by using the value from python configure.
--HG--
extra : rebase_source : 4d26bf30f3f125c4f75d42f79d8a80a4a0bf11ec
This will allow tests, etc to conditionally run depending on Stylo's
presence.
MozReview-Commit-ID: 3WHxNawP1qC
--HG--
extra : rebase_source : d4d983d37d3bfac1f9d465a3023b5bd5df52cd56
extra : source : 6baa88f7b1f4183ea57b9f8928556975042cad29
This deprecates PYTHON_UNIT_TESTS and replaces it with PYTHON_UNITTEST_MANIFESTS.
In the build system, this means python unittests will be treated the same as all
other test suites that use manifestparser. New manifests called 'python.ini' have
been created for all test directories containing python unittests.
MozReview-Commit-ID: IBHG7Thif2D
--HG--
extra : rebase_source : 11a92a2bc544d067946bbd774975140147458caa
The current way they are generated makes it so that it's not trivial for
the backends to figure that one depends on the other. While we should
eventually make things such that using FINAL_TARGET_PP_FILES works for
that, it's currently simpler to just use GENERATED_FILES.
--HG--
rename : build/application.ini => build/application.ini.in
extra : rebase_source : cad3460b65d99bdae3e6f1d9dd611e0a602ebfed
This patch does a few things:
1) Change all the in-tree tooltool manifests to contain sccache2 instead of the existing Python sccache
2) Change mozconfig.cache to point at sccache.
3) Lightly tweak the --with-cccache configure option to support sccache, and detect whether we're using ccache or sccache and set an option appropriately.
4) Add a MOZ_SCCACHE_VERBOSE_STATS option, and add a target in the top-level Makefile to make sccache spit out its stats at the end of the build. This is useful to see the cache hits/errors until we get something better.
5) Add MOZ_USING_SCCACHE to the build telemetry. Not that I think it will be immediately useful, but for future use.
MozReview-Commit-ID: 9lrdLwNj5Bm
--HG--
extra : rebase_source : d323457df10d0ee0ac5811940e518d9422a7e070
This patch contains a number of changes to the gyp_reader code:
* Add three new flags to GYP_DIRS:
** no_chromium, to skip forcing the includes/etc needed for chromium gyp files
** no_unified, to force building all sources without unification
** action_overrides, to pass scripts used when mapping gyp actions to moz.build GENERATED_FILES
* Handle the flags mentioned above in read_from_gyp
* Handle actions in gyp targets by mapping them to GENERATED_FILES, using scripts specified in the action_overrides flag. We don't try to handle the generic action case, we require special-casing for each action.
* Handle a subset of copies in gyp targets by mapping them to EXPORTS, just enough to handle the use of them for NSS exports.
* Handle shared_library and executable gyp targets
* Handle gyp target dependencies/libraries as USE_LIBS/OS_LIBS
* Handle generated source files
* Handle .def files in sources by mapping them to SYMBOLS_FILE
* Special-case some include_dirs:
** Map `<(PRODUCT_DIR)/dist/` to $DIST/include (to handle include paths for NSS exports)
** Map include_dirs starting with topobjdir to objdir-relative paths, to handle passing the NSPR include path to NSS
* split /build/gyp.mozbuild into two parts, with gyp_base.mozbuild containing generic bits, and gyp.mozbuild containing chromium-specific bits
MozReview-Commit-ID: FbDmlqDjRp4
--HG--
extra : rebase_source : d3fb470c589f92d8c956b9ecd550fb8df79ff5bc
GCC and Clang will colorize compiler output automatically if stdout is a
TTY. Unfortunately, when the build backend is invoked via `mach`,
stdout is not a TTY.
6e9a4c0b9cd8 (bug 1315785) changed mach so it exports an environment
variable indicating whether mach's original stdout is a TTY. This was
later used to add color flags to `cargo` invocations.
Building on that work, this patch adds color flags to compiler
invocations if the compiler supports color and a mach TTY is
detected. The result is that compiler output from `mach build`
will be colorized automatically if Clang or a modern version of
GCC is used.
The only issue I see with this is that Clang doesn't "unset" its color
sequences when printing a newline. As a result, mach's time line
prefixing can sometimes inherit "bold" or other stylings. AFAICT this is
only a minor cosmetic concern. GCC does not exhibit this issue.
MozReview-Commit-ID: 5Icu6aXGZBL
--HG--
extra : rebase_source : 5b2bf5a287fdf8075b3d7dde36b91f3c65b60728
The stable cargo now has all the features we need; pulling
a separate cargo nightly package is unnecessary.
MozReview-Commit-ID: FqWvSK0swsQ
--HG--
extra : rebase_source : 3659f8fa6d4a9a70c0731650aeced899519617f9
This should have been done when autoland came into existence.
MozReview-Commit-ID: HaWNq41mDvn
--HG--
extra : rebase_source : 1f8905a45388a147970b65d6d7e226600cf8afc2
fx-team is read only. We shouldn't be performing any more builds. The
configuration can be removed.
MozReview-Commit-ID: 3cbEnnOKwaZ
--HG--
extra : rebase_source : 1e3b69721f0615327c3882767f0b90ee10bce1cf
