Skip to content
Snippets Groups Projects
  1. Nov 22, 2024
  2. Nov 20, 2024
  3. Nov 13, 2024
  4. Nov 16, 2024
    • Matt Harbison's avatar
      contrib: add a script to build all of the wheels on macOS · 6aa4ee2bb128
      Matt Harbison authored
      This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`,
      except the default pythons to build can be inferred from `setup.py` and/or
      `pyproject.toml`, and all use the same configuration.  All we need to do is
      force the building of translation files, tell it to skip pypy wheels, and tell
      it to build universal2 wheels instead of for the current architecture.
      6aa4ee2bb128
  5. Nov 18, 2024
  6. Nov 15, 2024
  7. Nov 14, 2024
    • Matt Harbison's avatar
      contrib: add a bat file to build all of the wheels on Windows · ea9cbb0fa3d3
      Matt Harbison authored
      This is duplicated from the current CI config, to be able to build releases
      consistently outside of CI.  I don't like the duplication, but I'm not worried
      about things changing too often, so I'm not bothering with PowerShell or some
      form that would allow execution by the CI runner.  We should consider putting
      the config in `pyproject.toml`, where things like what python versions to
      support can be centrally controlled for all platforms.  The output directory is
      different from CI here, but that's fine because it is intended to run this on a
      system that is *not* hosting the CI setup, and `dist/` is more standard.  I
      dropped the `win32` part of the output because that implies the 32-bit Intel
      architecture.
      
      Apparently, arm64 builds are supported back to Python 3.9, but support is still
      experimental (with py3.13)[1].  The CI system starts arm64 support with Python
      3.11, because that's the first version that an arm64 Python installer was
      available on Windows.  This doesn't second guess that decision.
      
      The required `msgfmt.exe` was installed manually[2], as it isn't currently
      handled by the dependency installation script.  Otherwise, this was successfully
      used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3`
      installed.
      
      [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do
      [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe
      ea9cbb0fa3d3
    • Matt Harbison's avatar
      contrib: install the arm64 compiler tools in the Windows dependency script · 2e26c21f77ca
      Matt Harbison authored
      This lets us build arm64 wheels on Windows.  We should update from VS 2017 to
      VS 2019, but that can wait until there's a clean Windows system available.
      
      There's a little bit of handwaving here because I originally installed some
      packages on the CI system by checking boxes in the GUI installer to get arm64
      support, since I didn't know the name(s) of the things needed.  Exporting the
      configuration from the GUI installer showed the list of things present, and then
      I was able to run `vs_buildtools.exe` on another system that previously had this
      dependency script run a few years ago, with just this new arg.  That allowed the
      wheels to be built (the process failed on this second system prior to this).
      The only difference between the CI system configuration prior to installing
      arm64 stuff and this second system after, is the second system has the WinXP
      support component.  Surprisingly, the arm64 WDK and arm64 CRT or Universal CRT
      doesn't seem to be required.
      2e26c21f77ca
  8. Nov 15, 2024
  9. Nov 14, 2024
  10. Nov 15, 2024
  11. Nov 14, 2024
  12. Nov 13, 2024
  13. Nov 09, 2024
  14. Nov 10, 2024
  15. Nov 13, 2024
    • Pierre-Yves David's avatar
      setup: preserve version part after the "+" on Windows · 309f58964a9e
      Pierre-Yves David authored
      Code introduced in early 2010 (fb203201ce30) was dropping that part after "+".
      The rational is to preserve version on the format w.x.y.z where each part is a
      number. However we have not been using that format for a while (e.g. the rc
      suffix) and nobody reported any fire.
      
      So I am assuming that this code serve no purpose and I am dropping it. We can
      reintroduce a newer version of it (that would actually achieve its purpose) in
      the future if needed.
      309f58964a9e
    • Pierre-Yves David's avatar
      setup: make sure Rust build its extension for the right python · 124c944b71b2
      Pierre-Yves David authored
      Strictly speaking, only "PYTHON_SYS_EXECUTABLE" seems to be necessary, but I
      don't want to take a chances, as in testing "PYTHON" also had an effect.
      124c944b71b2
    • Pierre-Yves David's avatar
      clone: properly exclude rev-branch-cache from post clone cache warming · d57d1606049c
      Pierre-Yves David authored
      When adding "CACHE_REV_BRANCH" to "CACHES_ALL" in e51161b12c7e, I did not
      expected it to impact the clone steps. However the "CACHES_POST_CLONE" set is
      created rather creatively. (we should fix that, but not on stable)
      
      The benchmark caught a quite significant slowdown one hardlink and ssh-stream
      clones. Such slow down can be reduced to around ~5% by fully warming the cache
      before the clone. However keeping this expensive step away from the clone
      operation fully fix the slowdown and preserve the initial intend.
      
      
      Example slowdow for hardlink clone
      
      ### benchmark.name                               = hg.command.clone
        # bin-env-vars.hg.flavor                       = default
        # bin-env-vars.hg.py-re2-module                = default
        # benchmark.variants.explicit-rev              = none
        # benchmark.variants.issue6528                 = default
        # benchmark.variants.protocol                  = local-hardlink
        # benchmark.variants.pulled-delta-reuse-policy = default
        # benchmark.variants.resource-usage            = default
        # benchmark.variants.validate                  = default
       ## data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog
      6.8.2:  19.799752
      6.9rc0: 29.017493  (+46.55%, +9.22)
      after:  19.929341
      
       ## data-env-vars.name = mercurial-public-2018-08-01-zstd-sparse-revlog
      6.8.2:  0.468020
      6.9rc0: 1.701294 (+263.51%, +1.23)
      after:  0.471934
      
       ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
      6.8.2:  2.397564
      6.9rc0: 5.666641 (+137.41%, +3.28)
      after:  2.428085
      d57d1606049c
  16. Nov 12, 2024
  17. Nov 13, 2024
Loading