At some point we made L10NBASEDIR required. That means that
env L10NBASEDIR=... make chrome-AB_CD
takes the value set by configure. That is different than
make chrome-AB_CD L10NBASEDIR=...
which uses the value passed on the command line. Rather than making
the latter style work with `mach build`, we instead set the "correct"
value for L10NBASEDIR in automation.
We could remove the --with-l10n-base stanzas from many automation
mozconfigs, but there's some small advantage to keeping them explicit.
Perhaps eventually we will remove them -- hopefully after
standardizing l10n vs l10n-central!
Differential Revision: https://phabricator.services.mozilla.com/D15776
--HG--
extra : moz-landing-system : lando
Enough linux-based systems don't have libsecret that we can't make it a
requirement on linux. For those that do, however, we can dynamically load the
library at runtime. For those that don't, we can fall back to NSS.
Differential Revision: https://phabricator.services.mozilla.com/D9969
--HG--
extra : moz-landing-system : lando
The build system has skipped creating target static libraries for very
long, except in very specific cases.
We can actually do the same for host static libraries, for which we
don't even need the escape hatch to still allow to create static
libraries.
Depends on D15171
Differential Revision: https://phabricator.services.mozilla.com/D15172
--HG--
extra : moz-landing-system : lando
OBJ_SUFFIX is modified during the profile-generation phase to be i_o
instead of o/obj. _OBJ_SUFFIX is the unmodified value.
We don't actually do PGO for host objects, so we don't need to build the
objects with a different suffix.
Differential Revision: https://phabricator.services.mozilla.com/D15171
--HG--
extra : moz-landing-system : lando
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
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.
All but one of the current uses of DEFFILE use `SRCDIR + '/file.def'` to
get a srcdir-relative path anyway, and the other one wants an
objdir-relative path, so using Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
MSVC 15.8 linker dislikes forward slashes in the /OUT: parameter when it is generating a profile
--HG--
extra : rebase_source : 6980e212ea5a7ae21513805c22ec0e8ddeaa5dc1
Currently mozconfig.cache overrides a few build options for sccache.
This patch moves them into toolchain.configure so that the build system
will set them properly when sccache is in use. Additionally,
{CC,CXX}_WRAPPER are set in config.mk, so just avoid setting them when
sccache is in use.
Apparently the assembler was willing to accept the previous version, but
was unwilling to find the necessary symbols to link some JS code. This
version correctly quotes the data symbol and adds a little extra quoting
based on examining compiler-generated output.
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
This is tracked upstream at https://github.com/mozilla/libprio/issues/15
MozReview-Commit-ID: L5VWKdEitfB
--HG--
extra : rebase_source : c19472a8658c01a2edc69904e36a2c5409af1396
Previously we weren't passing the variables if we were compiling for Windows
when really we only want to do it if we're compiling with MSVC/clang-cl.
The MinGW-Clang build needs this.
Differential Revision: https://phabricator.services.mozilla.com/D3470
--HG--
extra : moz-landing-system : lando
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
For "real" Windows-to-Windows cross compiles, the setting of
HOST_OUTOPTION is incorrect: it assumes that if we are cross-compiling,
we'll be using `-o ` (GNU-style) rather than `-Fo` (MSVC-style). Our
normal x86 Windows automation builds are technically not
cross-compiles (host and target are both x86 Windows), so this case has
never bothered us before. But when compiling for AArch64 Windows, we
are really doing a cross-compile, and so we need to be more careful
about how we set this option; otherwise, host compilations will
mysteriously fail because they won't produce any output.