This is just an awkward feature of the FasterMake build system:
without a direct consumer, GENERATED_FILES aren't handled. We
"consume" them into a dummy directory that isn't packaged. Sadly, the
FasterMake generic rule doesn't handle relative directories smoothly,
so we have to special case that too.
Differential Revision: https://phabricator.services.mozilla.com/D12796
--HG--
extra : moz-landing-system : lando
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
By default, windows.h exposes a large number of problematic define statements
which are UpperCamelCase, such as a define from `CreateWindow` to
`CreateWindow{A,W}`.
As many of these names are generic (e.g. CreateFile, CreateWindow), they can
mess up Gecko code that may legitimately have its own methods with the same
names.
The header also defines some traditional SCREAMING_SNAKE_CASE defines which
can mess up our code by conflicting with local values.
This patch adds a simple code generator which generates wrappers for these
defines, and uses them to wrap the windows.h wrapper using the `stl_wrappers`
mechanism, allowing us to use windows.h in more places.
Differential Revision: https://phabricator.services.mozilla.com/D10932
Includes changes to support nasm's stricter include paths.
Supports falling back to yasm if nasm is missing.
Differential Revision: https://phabricator.services.mozilla.com/D9972
--HG--
extra : moz-landing-system : lando
The bulk of this patch is the new win64.asm, which is a more-or-less
direct copy of aarch64's sysv.S file, with modifications for armasm64's
peculiarities. The changes to ffi.c were minimal, mostly so that
arithmetic on `void*` conforms to the C standard.
SxS assemblies do not obey the usual DLL search order. It will make it possible
to load mozglue.dll from appdir even if the PreferSystem32Images mitigation is
enabled and System32 has a random mozglue.dll.
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
This also requires the 64-bits rust compiler and some build system
tweaks.
And since we make the 32-bits builds cross-compiles on CI, we also need
to adjust the MSVC build mozconfigs such that the host compiler points
to the right MSVC cl. Likewise, the DIA SDK is used for host things, so
use the 64-bits version or it.
Differential Revision: https://phabricator.services.mozilla.com/D7845
--HG--
extra : moz-landing-system : lando
This also requires the 64-bits rust compiler and some build system
tweaks.
Differential Revision: https://phabricator.services.mozilla.com/D7845
--HG--
extra : moz-landing-system : lando
This merely centralizes logic that was formerly used at multiple sites
into the single remaining use site.
None of the JAVA* flags have been used for a long time.
Differential Revision: https://phabricator.services.mozilla.com/D7313
--HG--
extra : moz-landing-system : lando
- Embed vendored Rust dependencies into the source package.
- Don't use --freeze with Cargo in JS standalone builds: since all the Rust
dependencies are vendored in, it won't trigger an update of the toplevel
Cargo.lock file for a standalone build in the non-package build case.
--HG--
extra : rebase_source : 06704eb326aad36a870586694a99964ad7a4dbfa
extra : histedit_source : 1502d976bc12a3eed17efaaf5dd2d4f46d0b00d5
This makes it more apparent which directory is responsible for creating
a particular generated file, program, library, etc. It is particularly
helpful in bug 1485081 since all node.py invocations will have similarly
named make targets, but run in different directories.
MozReview-Commit-ID: HlSOiL34i3M
Differential Revision: https://phabricator.services.mozilla.com/D6822
--HG--
extra : moz-landing-system : lando
Add support for |with Files('a/**', 'b/**')| in mozbuild config files.
MozReview-Commit-ID: IoM4qfEhXXc
Differential Revision: https://phabricator.services.mozilla.com/D5315
--HG--
extra : moz-landing-system : lando
BUILD_TOOLS was only ever used for things that another variable provides
equally well. Removing BUILD_TOOLS means that we can remove win_srcdir
and WIN_TOP_SRC as well.