- Jun 21, 2022
-
-
Emilio Cobos Álvarez authored
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
-
- Sep 29, 2021
-
-
Mike Hommey authored
Nothing uses it anymore. Differential Revision: https://phabricator.services.mozilla.com/D126857
-
- Aug 11, 2021
-
-
Mike Hommey authored
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
-
- Jun 02, 2021
-
-
Mike Hommey authored
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
-
- May 04, 2021
-
-
Nick Alexander authored
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
-
- Jan 11, 2021
-
-
David Major authored
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
-
- Oct 15, 2020
-
-
Ricky Stewart authored
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
-
- Sep 09, 2020
-
-
Mike Hommey authored
Bug 1663850 - Remove unused variables in config/config.mk. r=firefox-build-system-reviewers,rstewart Differential Revision: https://phabricator.services.mozilla.com/D89551
-
- Aug 28, 2020
-
-
Mike Hommey authored
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
-
- Aug 11, 2020
-
-
Mike Hommey authored
Differential Revision: https://phabricator.services.mozilla.com/D86639
-
- Aug 08, 2020
-
-
Mike Hommey authored
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
-
- Jul 09, 2020
-
-
Mike Hommey authored
Differential Revision: https://phabricator.services.mozilla.com/D82866
-
- May 31, 2020
-
-
Axel Hecht authored
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
-
- May 27, 2020
-
-
Axel Hecht authored
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
-
- May 07, 2020
-
-
Ricky Stewart authored
`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
-
- May 05, 2020
-
-
Ricky Stewart authored
Differential Revision: https://phabricator.services.mozilla.com/D72478
-
- May 01, 2020
-
-
Bogdan Tara authored
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)
-
Ricky Stewart authored
Differential Revision: https://phabricator.services.mozilla.com/D72478
-
- Apr 09, 2020
-
-
Mike Hommey authored
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
-
- Feb 24, 2020
-
-
David Major authored
Differential Revision: https://phabricator.services.mozilla.com/D63888 --HG-- extra : moz-landing-system : lando
-
- Jan 02, 2020
-
-
Nathan Froyd authored
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
-
- Dec 09, 2019
-
-
Mike Shal authored
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
-
- Nov 27, 2019
-
-
Ricky Stewart authored
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
-
- Jul 18, 2019
-
-
Makoto Kato authored
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
-
Tom Ritter authored
Differential Revision: https://phabricator.services.mozilla.com/D38019 --HG-- extra : moz-landing-system : lando
-
- Jun 28, 2019
-
-
Gijs Kruitbosch authored
Differential Revision: https://phabricator.services.mozilla.com/D35469 --HG-- extra : moz-landing-system : lando
-
- Jun 27, 2019
-
-
Andreea Pavel authored
-
Gijs Kruitbosch authored
Differential Revision: https://phabricator.services.mozilla.com/D35469 --HG-- extra : moz-landing-system : lando
-
- Jun 26, 2019
-
-
Mike Hommey authored
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
-
- Jun 21, 2019
-
-
Mike Hommey authored
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
-
- May 24, 2019
-
-
Nathan Froyd authored
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
-
- Apr 09, 2019
-
-
Henri Sivonen authored
Differential Revision: https://phabricator.services.mozilla.com/D26272 --HG-- extra : moz-landing-system : lando
-
- Mar 05, 2019
-
-
Mike Hommey authored
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
-
- Feb 25, 2019
-
-
Ted Mielczarek authored
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
-
- Feb 14, 2019
-
-
Mike Hommey authored
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
-
- Jan 28, 2019
-
-
Mike Hommey authored
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
-
- Jan 23, 2019
-
-
Mike Hommey authored
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
-
- Jan 08, 2019
-
-
Andreea Pavel authored
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)
-
- Jan 07, 2019
-
-
Nick Alexander authored
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
-
- Jan 08, 2019
-
-
Henri Sivonen authored
-