Are the commands “cmake -build . --target package” and “cpack .” fully equivalent?
If yes, why would one ever use the former?
(One possible reason I know: Under Windows, cpack
is ambiguous, as Chocolatey has an obsolete cpack.exe
.)
Are the commands “cmake -build . --target package” and “cpack .” fully equivalent?
If yes, why would one ever use the former?
(One possible reason I know: Under Windows, cpack
is ambiguous, as Chocolatey has an obsolete cpack.exe
.)
They are more or less equivalent, yes. The package
target exists so you can run make package
or ninja package
. Running cmake --build . --target package
does seem a little silly to me… if you’re using the CMake command line tools anyway, you might as well use cpack
at that point.
The cmake --build . --target package
command is logically equivalent to running cpack
, but there are important differences:
cmake --build . --target package
will also build the all
target first, whereas running cpack
directly won’t. Perhaps @kyle.edwards can confirm this?cpack
directly supports many options that allow you to control the behavior (e.g. specifying which package generators to use), whereas cmake --build . --target package
can only support the defaults set by the project.cpack -C ...
. There is no equivalent for cmake --build . --target package
, which can only build/package a single configuration.Yes, package
is a build-in target in CMake with dependeny to ALL
.
I mentioned that here yesterday:
cpack .
will also run the install
target on your project, so it also basically has a dependency on ALL
as well.
Turns out that’s not accurate. cpack
will run the cmake_install.cmake
script, it won’t build the install
target. I did some local testing to confirm that my original comment was correct: cmake --build . --target package
will also build the all
target first, whereas running cpack
directly won’t.
Hmm, guess I was mistaken then. There was definitely some reason I had split the packaging steps out from the main build in our superbuilds, but maybe that was due to looking to support different packaging layouts with a single build tree (where install dirs depend on the packaging format).