[HIPIFY][build][install][fix] Pass USE_SOURCE_PERMISSIONS when installing scripts

[stellaraccident]

Pass USE_SOURCE_PERMISSIONS when installing scripts.

Without this, hipify-perl and friends are installed with non-executable permissions, requiring after the fact fixup.

[emankov]

Please rebase - your PR should only include your commit(s) related to the PR w/o any merges and others' commits.

[stellaraccident]

Ptal

[emankov]

LGTM

[emankov]

@raramakr, could you have a look, too? Thanks.

[raramakr]

For installing shell scripts cmake recommends to use install( PROGRAMS ..) as in line number 194-195 of CMakeLists.txt

(https://cmake.org/cmake/help/latest/command/install.html#programs)
The PROGRAMS form is identical to the FILES form except that the default permissions for the installed file also include OWNER_EXECUTE, GROUP_EXECUTE, and WORLD_EXECUTE. This form is intended to install programs that are not targets, such as shell scripts. Use the TARGETS form to install targets built within the project.

[stellaraccident]

For installing shell scripts cmake recommends to use install( PROGRAMS ..) as in line number 194-195 of CMakeLists.txt

(https://cmake.org/cmake/help/latest/command/install.html#programs) The PROGRAMS form is identical to the FILES form except that the default permissions for the installed file also include OWNER_EXECUTE, GROUP_EXECUTE, and WORLD_EXECUTE. This form is intended to install programs that are not targets, such as shell scripts. Use the TARGETS form to install targets built within the project.

Indeed - that explains the itch I was having because I hadn't encountered this before (I usually use one of the more recommended forms). I can try this change in my project when I get back through my patch queue. Also fine if someone else wants to land a bug fix.

[emankov]

Hi @stellaraccident,

First, thanks for your contribution.
Second, are you going to incorporate hipify-perl into the existing install(PROGRAMS..., or do you want us to do it?

Thanks!

[stellaraccident]

I've got a growing set of patches and would accept the help in taking this over, if you're offering. It is a bit of a pain to rebase and test in the rig I have.

[searlmc1]

Hi @stellaraccident ,

Is it critical to land this in the ROCm:rocm-6.3.x branch ? If so, we need to coordinate with ROCm-devOps as the source-of-truth for that branch is internal. Also, I assume this should land in the amd-staging branch. E.g., I assume this issue also exists in amd-staging / also needs to be fixed there.

Thanks much

[stellaraccident]

No it is not required to land on 6.3.x. That is just where the diffbase originated from. Aakash (not sure of his GH id) is picking all of these patches from me up and working on getting them onto mainline (and working on getting our build rebased on mainline).

[searlmc1]

OK ; sounds good; they should land in staging first ; staging gets promoted to mainline . Between you | me | Evgeny | Aakash , we can make sure they land in the right places. fwiw: Aakash is @amd-aakash ; as Evgeny said, thanks for the patches .