improve CPIO creation

[axel-h]

• reduce redundancy by using some helper variables
• use verbose cpio flags
• Improve maintainability for CPIO creation
• allow passing a directory also in the CPIO archive name, so root binary folder pollution can be avoided

[kent-mcleod]

This pattern is repeated a lot throughout the CMake files. I recall it's partially because if (${MAKE_CPIO_UNPARSED_ARGUMENTS}) unexpectedly evaluates to false for almost all string values as CMake's described behavior (https://cmake.org/cmake/help/latest/command/if.html).

Using if(MAKE_CPIO_UNPARSED_ARGUMENTS) is shorter and you know that this tests if the variable is defined and defined to non-false values. But it would be easy to misread something like if(${MAKE_CPIO_UNPARSED_ARGUMENTS} or if("${MAKE_CPIO_UNPARSED_ARGUMENTS}") as testing for truth if you aren't more familiar with the if() gotchas . In these cases, if the variable contains a string it will always evaluate to false unless the contents match the truthy string values (eg ON, TRUE, etc). So while "${MAKE_CPIO_UNPARSED_ARGUMENTS}" STREQUAL "") is more verbose, it's probably a good pattern to leave around for explicitly testing for a non-empty string as it doesn't rely on understanding any if() testing gotchas.

[axel-h]

I agree with all points. This is the outcame from digging into CMake usage and a long term plan to use the language as it seems intended nowadays. I can move this to a separate PR to make the intention more clear. There are more places where this could be changed to clarify what checks are non-trivial.

[axel-h]

I have remove the commit

[axel-h]

Fixed a few typos.

[axel-h]

Rebased. Can we merge this now, do the other PRs that use this get unblocked?

[axel-h]

rebased and improved the absolute/relative path handling a bit more.

[kent-mcleod]

When I originally approved this, it was a much smaller change: e5981ae, so my approval doesn't apply to the current version of the PR.

[kent-mcleod]

I don't consider that this property is needed unless CMake implicitly adds it for all files it generates in the build directory already. Trying to detect and recover the build directory becoming corrupted isn't the responsibility of the build scripts.

[axel-h]

It's a convenience feature I found quite useful when experimenting with the archive creation. In general, when debugging CMake things, I often corrupt the build folder or delete files on purpose to force partial regeneration. And my expectation from proper dependency management is, that everything in the build folder should be re-generated automatically.

referred to an earlier version

[axel-h]

When I originally approved this, it was a much smaller change: e5981ae, so my approval doesn't apply to the current version of the PR.

The older approach did not work in some corner cases.