]> granicus.if.org Git - graphviz/commit
CI: call CPack via CMake smattr/a6d69c3e-65f6-499d-9bf0-0d3a484aa3d0
authorMatthew Fernandez <matthew.fernandez@gmail.com>
Fri, 30 Sep 2022 04:36:07 +0000 (21:36 -0700)
committerMatthew Fernandez <matthew.fernandez@gmail.com>
Fri, 30 Sep 2022 04:36:07 +0000 (21:36 -0700)
commit71fd7068d96ca2351629ecc725178f4d9430eff5
tree0172eca81ad0ac30ec8681127d25fae421509fbb
parentebdc53dd05384c30351eae13370ea1840b663466
CI: call CPack via CMake

CPack is CMake’s “packaging driver,” exposed as `cpack.exe`. Yet if you
call `cpack.exe` in some CI environments, you will find the binary in your
`$PATH` is _not_ CMake’s packaging driver. This is what the logic in the Windows
setup script that is being removed in this commit was attempting to detect and
workaround or diagnose: a `cpack.exe` in your `$PATH` that is some unrelated and
unhelpful platform management executable.

But there is a simpler way. CMake’s docs¹ tell us:

  Instead of `cpack`, one may call `cmake --build . --target package` or
  `make package` or `ninja package`.

In this change, we drop the `cpack` and `$PATH` workarounds and just call
`cmake`, relying on it to know where its own packaging driver is.

¹ https://cmake.org/cmake/help/latest/module/CPack.html
ci/build.sh
ci/windows_build.py
windows/bin/setup-build-utilities.ps1