Skip to content
Snippets Groups Projects
  1. Jun 21, 2022
  2. Sep 29, 2021
  3. Aug 11, 2021
    • Mike Hommey's avatar
      Bug 1724606 - Replace uses of MACOSX_DEPLOYMENT_TARGET env variable with... · d8730821
      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
      d8730821
  4. Jun 02, 2021
  5. May 04, 2021
  6. Jan 11, 2021
    • David Major's avatar
      Bug 1685758 - Increase stack size on win32 debug r=firefox-build-system-reviewers,mhentges · c2db81c2
      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
      c2db81c2
  7. Oct 15, 2020
    • Ricky Stewart's avatar
      Bug 1670357 - Remove `make` targets for cleaning: `clean`, `realclean`,... · 362abcf9
      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
      362abcf9
  8. Sep 09, 2020
  9. Aug 28, 2020
  10. Aug 11, 2020
  11. Aug 08, 2020
    • Mike Hommey's avatar
      Bug 1537703 - Use llvm-rc instead of rc.exe. r=mhentges,froydnj · 527e6672
      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
      527e6672
  12. Jul 09, 2020
  13. May 31, 2020
  14. May 27, 2020
  15. May 07, 2020
    • Ricky Stewart's avatar
      Bug 1633156 - Don't emit cached table files from ply r=glandium · 933b3522
      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
      933b3522
  16. May 05, 2020
  17. May 01, 2020
  18. Apr 09, 2020
  19. Feb 24, 2020
  20. Jan 02, 2020
  21. Dec 09, 2019
    • Mike Shal's avatar
      Bug 1557788 - Remove OBJS_VAR_SUFFIX & .i_o suffix for instrumented builds;... · 580f0c29
      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
      580f0c29
  22. Nov 27, 2019
  23. Jul 18, 2019
  24. Jun 28, 2019
  25. Jun 27, 2019
  26. Jun 26, 2019
  27. Jun 21, 2019
  28. May 24, 2019
  29. Apr 09, 2019
  30. Mar 05, 2019
    • Mike Hommey's avatar
      Bug 1531680 - Don't disable LTO on standalone profile-generate builds. r=chmanchester · fa7300a7
      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
      fa7300a7
  31. Feb 25, 2019
    • Ted Mielczarek's avatar
      bug 1481614 - detect icecream usage in build telemetry. r=chmanchester,glandium · 0539de89
      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
      0539de89
  32. Feb 14, 2019
    • Mike Hommey's avatar
      Bug 1512504 - Remove support for MSVC. r=froydnj · ef3ad686
      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
      ef3ad686
  33. Jan 28, 2019
  34. Jan 23, 2019
  35. Jan 08, 2019
    • Andreea Pavel's avatar
      Backed out 5 changesets (bug 256180) for failing win xpcshell at... · f5a1a0f0
      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)
      f5a1a0f0
  36. Jan 07, 2019
    • Nick Alexander's avatar
      Bug 1496190 - Pre: Default L10NBASEDIR to correct value in automation. r=Callek · 2027f25d
      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
      2027f25d
  37. Jan 08, 2019
Loading