This should work. I don't recall there being any linker honoring these
but I might be wrong.

Differential Revision: https://phabricator.services.mozilla.com/D149609

Nothing uses it anymore.

Differential Revision: https://phabricator.services.mozilla.com/D126857

Bug 1724606 - Replace uses of MACOSX_DEPLOYMENT_TARGET env variable with -mmacosx-version-min flag. r=firefox-build-system-reviewers,andi

They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.

On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.

Differential Revision: https://phabricator.services.mozilla.com/D122145

It's not practically make a difference (the flags we end up setting it
to don't do anything when linking all the wasm files into one).

Differential Revision: https://phabricator.services.mozilla.com/D116437

Bug 1707030 - Return to having NSDISTMODE=copy impact INSTALL. r=firefox-build-system-reviewers,mhentges

This reverts [part of Bug
1255485](https://hg.mozilla.org/mozilla-central/rev/5888578c22f8dc006cfd6a405c9fc53b2df73b44).

It should have been reverted in Bug 1641291, which allowed
NSDISTMODE=copy to impact build manifests.  This is useful when
cross-compiling: this stops some symlinks within the object directory
itself, say from `dist/include` to an object directory.

Differential Revision: https://phabricator.services.mozilla.com/D113149

With clang 12, win32 debug tests run out of stack in the 1000-deep layout crashtests.

Usually when this type of thing happens, it's because the compiler made a drastically heavier inlining decision along the recursive part of the stack, with a difference in the hundreds of bytes, and we pay that price of that space 1000 times. In those cases we normally try to snip out the heavy piece with a MOZ_NEVER_INLINE.

However, in this case, the difference between old and new compilers was only something like 16 bytes of the cyclical piece. This suggests that we're already up pretty close against the limit, and we're only a bad day away from failing tests even with existing clang. This only happens in debug builds since they have lots of logging helpers on the stack. Release builds are still well under the limit.

So I propose to increase the stack limit in debug. While we normally have to be pretty careful about address space on win32, it should be less of a concern with these non-shipping builds.

Differential Revision: https://phabricator.services.mozilla.com/D101196

Bug 1670357 - Remove `make` targets for cleaning: `clean`, `realclean`, `clobber`, `distclean`, `clobber_all`, `everything` r=firefox-build-system-reviewers,mhentges

The `clobber` targets are superseded by `mach clobber`, so we don't need them for any reason. The `clean` target is meant to get you to a post-`configure` state, but it doesn't really work, and if it's necessary for you to be in that state for some reason you can just clobber and re-`configure`, so it doesn't seem worth it to get it working again. Instead, delete all of them. Also delete `everything` which is not useful when `clobber` doesn't exist.

Differential Revision: https://phabricator.services.mozilla.com/D93514

Bug 1663850 - Remove unused variables in config/config.mk. r=firefox-build-system-reviewers,rstewart

Differential Revision: https://phabricator.services.mozilla.com/D89551

Bug 1620133 - Allow generated file rules to run in parallel in a given directory. r=firefox-build-system-reviewers,rstewart

Bug 1645986 solved the problem for most generated files by moving their
rules to the top-level, but we're going to add rules that will end up in
subdirectories, so we have to solve the same problem again, in the
subdirectories.

Differential Revision: https://phabricator.services.mozilla.com/D88389

Differential Revision: https://phabricator.services.mozilla.com/D86639

This makes us use one less tool from MSVC, and removes one more use of wine
in cross builds.

We replace the call to either rc/llvm-rc or windres with a wrapper script.
While the script is not strictly needed for the latter, we use a wrapper
in that case anyway because it's one step towards fixing bug 1498414.
For llvm-rc, however, we need a wrapper because llvm-rc doesn't preprocess
on its own, so the wrapper does that too.

The wrapper script also allows to deal with the default flags passed to
llvm-rc or windres, rather than inherit them from old-configure.

We also need to explicitly pass the codepage to llvm-rc, which was not
necessary with rc (presumably, llvm-rc has a different default).

While here, remove the unused WINDRES subst from js/src/old-configure.in.
Also, while here, we remove --use-temp-file, because as described in the
linked bug and in the windres manual page, it was used to work around bugs
on Windows 98 and earlier.

Differential Revision: https://phabricator.services.mozilla.com/D86312

Differential Revision: https://phabricator.services.mozilla.com/D82866

This was regressed by bug 1641791, mostly for the lack of comments in at
least two places.

Differential Revision: https://phabricator.services.mozilla.com/D77590

l10n-merge creates a full merge dir for a while now, let's
simplify the build logic to only read from that directory
during repacks and langpacks.

Differential Revision: https://phabricator.services.mozilla.com/D77023

`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)

In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](https://github.com/dabeaz/ply/tree/1fac9fed647909b92f3779dd34beb8564f6f247b/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.

Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:

```
PLY no longer writes cached table files.  Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```

In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.

That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.

Differential Revision: https://phabricator.services.mozilla.com/D73484

Differential Revision: https://phabricator.services.mozilla.com/D72478

Backed out 6 changesets (bug 1632916, bug 1599658, bug 1633037, bug 1633039, bug 1633016, bug 1632920) for SA bustages CLOSED TREE

Backed out changeset 332ce0963b4e (bug 1633039)
Backed out changeset a9904cbc40d9 (bug 1633037)
Backed out changeset d06b0ec349f8 (bug 1599658)
Backed out changeset 8fd300cad80f (bug 1633016)
Backed out changeset f8820941c703 (bug 1632916)
Backed out changeset ac9c2c8746ed (bug 1632920)

Differential Revision: https://phabricator.services.mozilla.com/D72478

Also enable all config/tests with python3. unit-nsinstall.py was the
last one that didn't pass with python 3.

Switch the test to using @unittest.skipIf and disable the subprocess
test because we purposely broke running nsinstall.py independently with
python 2.

Differential Revision: https://phabricator.services.mozilla.com/D70160

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D63888

--HG--
extra : moz-landing-system : lando

At the moment, everything we're putting in a wasm sandbox is not
performance-critical, so we don't need PGO.  It's also not clear that
PGO would actually work properly with code that's been run through
wasm.  Let's leave figuring that out until, at the very least, the wasm
toolchain is a little more mature.

Differential Revision: https://phabricator.services.mozilla.com/D58513

--HG--
extra : moz-landing-system : lando

Bug 1557788 - Remove OBJS_VAR_SUFFIX & .i_o suffix for instrumented builds; r=firefox-build-system-reviewers,chmanchester

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

Bug 1594867 - Add moz.build/backend bits to specify files that should be built as a sandboxed wasm library r=firefox-build-system-reviewers,mshal

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

Bug 1567069 - Set valid _DEPEND_CFLAG for host compiler when target and host are different type. r=glandium

Actually we set _DEPEND_CFLAGS to both host and target compiler. But if host and target are different compiler type, we may pass invalid option.

Differential Revision: https://phabricator.services.mozilla.com/D38457

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D38019

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D35469

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D35469

--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

Bug 1560527 - Enable make backend verbose mode automatically rather than relying on mach setting it. r=froydnj

This makes running without mach more consistent. e.g. running
`make -C $objdir/toolkit/library/rust target` makes the cargo log
verbose, and adding `-s` makes it less verbose.

Differential Revision: https://phabricator.services.mozilla.com/D35521

--HG--
extra : moz-landing-system : lando

We're moving to IR-level PGO instrumentation for clang-cl.  We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation.  We therefore
we no longer need this code.

Differential Revision: https://phabricator.services.mozilla.com/D31134

--HG--
extra : moz-landing-system : lando

Differential Revision: https://phabricator.services.mozilla.com/D26272

--HG--
extra : moz-landing-system : lando

On one-go MOZ_PGO builds, it's generally not wanted to do LTO during the
profile-generate phase. And the build system doesn't really support
different build options between both phases in this case, so we relied
on MOZ_PROFILE_GENERATE to disable the LTO flags.

However, in standalone profile-generate builds, if --enable-lto is
passed explicitly, the build should respect that choice.

So instead of checking MOZ_PROFILE_GENERATE to disable the LTO flags,
we disable them when MOZ_LTO is not set, and we force it to be disabled
during the profile-generate phase of one-go MOZ_PGO builds.

Differential Revision: https://phabricator.services.mozilla.com/D21659

--HG--
extra : moz-landing-system : lando

This patch adds detection for when icecream is in use to build telemetry.
icecream is commonly enabled in two ways: by either setting CC/CXX to point
to icecream's cc/c++ symlinks, or by setting adding
mk_add_options 'export CCACHE_PREFIX=icecc' to a mozconfig when also using
ccache. For the former, this patch adds a simple configure check to see
if CXX is a symlink to a file named 'icecc'. For the latter this patch adds
CCACHE_PREFIX as a configure subst to capture the value.

We don't currently have a facility for writing telemetry tests that depend on
configure values. Local manual testing shows that it does work as expected.

Differential Revision: https://phabricator.services.mozilla.com/D18138

--HG--
extra : moz-landing-system : lando

Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
  worked in non-ASCII cases.

This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.

Depends on D19614

Differential Revision: https://phabricator.services.mozilla.com/D19615

--HG--
extra : moz-landing-system : lando

This was added back in bug 1414287, as a sort of quick hack, but since
then, bug 1515528 fixed things such that the hack is not necessary
anymore, and bug 1523201 allows for things to work on automation
(HOST_LINKER ended up being wrong because of the lack of "proper" VC
configuration on automation)

Differential Revision: https://phabricator.services.mozilla.com/D17790

--HG--
extra : moz-landing-system : lando

The only use in configure itself is for a MSVC version check that is now
always true (we don't accept versions < 19.15 anymore).

The only uses in the build system are in code that could just use
CC_TYPE instead.

Differential Revision: https://phabricator.services.mozilla.com/D17207

--HG--
extra : moz-landing-system : lando

Backed out 5 changesets (bug 256180) for failing win xpcshell at xpcshell.ini:toolkit/mozapps/extensions/test/xpcshell/test_temporary.js on a CLOSED TREE

Backed out changeset e85e41f84971 (bug 256180)
Backed out changeset 125ebcfac58d (bug 256180)
Backed out changeset bc2e0a89d88e (bug 256180)
Backed out changeset b696df615c8b (bug 256180)
Backed out changeset 2d69841d2eb7 (bug 256180)

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