Skip to content
Snippets Groups Projects
  1. 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
  2. Nov 15, 2024
  3. Nov 14, 2024
  4. Nov 15, 2024
  5. Nov 14, 2024
  6. Nov 13, 2024
  7. Nov 09, 2024
  8. Nov 10, 2024
  9. 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
  10. Nov 12, 2024
  11. Nov 13, 2024
  12. Nov 09, 2024
    • Pierre-Yves David's avatar
      wheel: add a job uploading nightly build · b8efa9013d3f
      Pierre-Yves David authored
      There are various questions around when to actually run it, and which jobs to
      run on the default branch, but having a working job we can decide to run
      manually (by running the manual dependencies) is a good step to get the wheel
      story from one end to the other.
      
      See inline comment for more details.
      b8efa9013d3f
    • Pierre-Yves David's avatar
      wheel: add a platform level to the wheel directories · 05addf266f6f
      Pierre-Yves David authored
      One day, we will gather all wheel in a single directory and be able to pick the
      right one programmatically. This days is not today…
      
      This will help clarify things if we fetch all artifacts at the same time.
      05addf266f6f
  13. Nov 13, 2024
  14. Nov 09, 2024
  15. Nov 10, 2024
  16. Nov 12, 2024
  17. Nov 10, 2024
  18. Nov 09, 2024
  19. Nov 10, 2024
  20. Nov 09, 2024
  21. Nov 10, 2024
Loading