Extremely common file paths on macOS like `/Users/...` are interpreted
as `/U...` flags by `clang-cl`. This is so common that there's a
`-Wslash-u-filename` warning. Ensure that file paths are considered
paths when compiling by terminating options with `--`.
This commit handles everything except assembler invocations, because
at least `nasm` doesn't handle `--`.
Differential Revision: https://phabricator.services.mozilla.com/D77119
iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
This needs a few adjustments to the autobinscope script because running
binscope currently creates an HTML file in the binscope directory, and
when multiple binscopes run at the same time (which happens during the
build with the changes to run it on all executables and libraries), all
but one fail to open the HTML file for write access.
So add a flag to create that file in a temporary directory.
While here, remove log_file_path, which hasn't been used since
bug 1448306.
Differential Revision: https://phabricator.services.mozilla.com/D67422
--HG--
extra : moz-landing-system : lando
This needs a few adjustments to the autobinscope script because running
binscope currently creates an HTML file in the binscope directory, and
when multiple binscopes run at the same time (which happens during the
build with the changes to run it on all executables and libraries), all
but one fail to open the HTML file for write access.
So add a flag to create that file in a temporary directory.
While here, remove log_file_path, which hasn't been used since
bug 1448306.
Differential Revision: https://phabricator.services.mozilla.com/D67422
--HG--
extra : moz-landing-system : lando
- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--HG--
extra : moz-landing-system : lando
- -NOLOGO is used to hide the banner that MSVC displays by default. It's
a no-op with clang-cl, no need to keep it now that we don't support
MSVC.
- -utf-8 is only passed when the compiler is not GCC-ish and not
clang-cl, which used to mean MSVC, but now means no compiler.
Differential Revision: https://phabricator.services.mozilla.com/D62705
--HG--
extra : moz-landing-system : lando
`lucetc` by default will invoke `ld` directly, which is usually not what
we want, particularly when cross-compiling. Instead, let's invoke the
compiler, which will do the hard work of determining the correct linker
to use, and we'll also explicitly specify `LDFLAGS`, since the default
`LDFLAGS` from `lucetc` assume you're invoking the linker directly.
Depends on D62797
Differential Revision: https://phabricator.services.mozilla.com/D62798
--HG--
extra : moz-landing-system : lando
We're going to need this for handling Mac cross compiles correctly.
Depends on D62795
Differential Revision: https://phabricator.services.mozilla.com/D62796
--HG--
extra : moz-landing-system : lando
Baby steps. Working towards not using $(MT), let's unsupport what we
currently don't rely on (and in case someone would try to rely on it,
throw an error).
Differential Revision: https://phabricator.services.mozilla.com/D61948
--HG--
extra : moz-landing-system : lando
In 1-tier PGO builds that shared the objdir between the instrumented and
profile-use builds, the instrumented build objects used a different
suffix (.i_o) to separate them from the profile-use build (which uses
the default .o suffix). These builds are now always in separate objdirs,
and don't need special suffix rules anymore.
As a bonus, this helps fix an issue with buildid.cpp continually
rebuilding because libxul_so.list always lists the inputs as *.o, which
don't exist if we're using a .i_o suffix. Make would always re-create
buildid.cpp and therefore libxul.so in the instrumented build even when
nothing has changed.
Differential Revision: https://phabricator.services.mozilla.com/D56115
--HG--
extra : moz-landing-system : lando
This was used for Windows MSVC PGO builds that re-used the objdir. We
don't use MSVC for PGO anymore, and we don't re-use the objdir.
Differential Revision: https://phabricator.services.mozilla.com/D56114
--HG--
extra : moz-landing-system : lando
MOZ_1TIER_PGO was a temporary hack to support 1-tier PGO builds while
they were being ported to 3-tier. Now that all builds are 3-tier, it can
be removed.
Differential Revision: https://phabricator.services.mozilla.com/D56112
--HG--
extra : moz-landing-system : lando
Add backend stuff to build sandboxed wasm libraries. (Don't actually update any moz.build files to consume this yet.)
Differential Revision: https://phabricator.services.mozilla.com/D54152
--HG--
extra : moz-landing-system : lando
To get an accurate backtrace if the run task crashes, we need the
symbols from the instrumented build.
Depends on D53716
Differential Revision: https://phabricator.services.mozilla.com/D53717
--HG--
extra : moz-landing-system : lando
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
-Fd is the parameter accepted by clang. -PDB is the parameter accepted by lld-link. Additionally, to produce a pdb you apparently also need the -DEBUG flag
Differential Revision: https://phabricator.services.mozilla.com/D43525
--HG--
extra : moz-landing-system : lando
Make depend files related to object files are only really useful when
the corresponding build targets are being processed. OTOH, when they are
included too broadly, when the build recurses in the same directory for
different targets (e.g. target-objects, target, host-objects and/or
host), it is possible for one of them to start creating depend files
that the others would end up reading, and those reads might be
incomplete, possibly leading to build failures because Make think it's
malformed.
So, we only include the object files's depend files in when Make is
explicitly treating a target that will build objects.
Differential Revision: https://phabricator.services.mozilla.com/D42766
--HG--
extra : moz-landing-system : lando
Make the target and host targets depend on those, and flatten the
dependencies.
That is, instead of chains like:
browser/app/target: mozglue/build/target
mozglue/build/target: memory/build/target
we now have:
browser/app/target: browser/app/target-objects \
mozglue/build/target-objects \
memory/build/target-objects
Which means Make can feel free to build the object files in browser/app
before building other dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D42252
--HG--
extra : moz-landing-system : lando
With the addition of toolkit/library/build because of the rust
shenanigans, bug 1573314 and bug 1572046 don't do anything useful
anymore. We're going to do something better anyways.
Differential Revision: https://phabricator.services.mozilla.com/D42251
--HG--
extra : moz-landing-system : lando
Apart from the need to link them last, they don't actually need to be
treated any different from normal static libraries.
Differential Revision: https://phabricator.services.mozilla.com/D42249
--HG--
extra : moz-landing-system : lando
When a directory, like toolkit/library, builds both a static and a
shared library, and another, like toolkit/library/gtest, depends on the
static part, it currently needs to wait for the shared library to be
finished building, preventing both libraries being built in parallel.
By separating shared libraries to a different target, we allow more
parallelism to the build.
Differential Revision: https://phabricator.services.mozilla.com/D41099
--HG--
extra : moz-landing-system : lando
We needed these rules and bits for the QT widget port, but there's no
longer a QT port in the tree, so we might as well remove them.
Differential Revision: https://phabricator.services.mozilla.com/D38886
--HG--
extra : moz-landing-system : lando
The condition that enabled ELOG to do something has been broken since
bug 279212 landed two years ago, because MAKEFLAGS doesn't contain the
dash for flags, so looking for "-s" never did anything.
Bug 1560527 changed the condition to !BUILD_VERBOSE_LOG, which as of the
previous commit, does work. This would restore the old behavior, at the
expense of build time, since it involves wrapping in a shell script,
which is not necessarily desirable (and hasn't been done for two years
now)
Differential Revision: https://phabricator.services.mozilla.com/D35967
--HG--
extra : moz-landing-system : lando
Bug 1560527 was not supposed to change verbosity for mach build, but it
turns out it did, because the ifeq it copied from one place to another
was wrong in the first place.
While here, replace a ifeq that did work with the now equivalent
BUILD_VERBOSE_LOG.
Differential Revision: https://phabricator.services.mozilla.com/D35966
--HG--
extra : moz-landing-system : lando
