binary executables should use '.exe' suffix on Windows

[2bndy5]

I've been trying this out on my Windows machine, and The OS didn't know that the binaries were executable files because they didn't have the .exe file suffix.

Example after installing v12 in a python venv

Executing `clang-format-12` asked me what program to open the file with.

After changing .exe to the clang-format binary file's suffix, I got the expected behavior:

(venv) PS path\to\GitHub\cpp-linter-action> clang-format-12.exe --version
clang-format version 12.0.0

I'm guessing the fix for this would involve modifying the call to

clang-tools-pip/clang_tools/install.py

Line 66 in 4b49644

def move_and_chmod_binary(old_file_name, new_file_name, directory) -> None:

or simply adjusting the new_file_name arg for the Windows platform within the mv_and_chmod() function.

Other Windows considerations

os.chmod() has limited support on Windows. The docs specifically note:

Although Windows supports chmod(), you can only set the file’s read-only flag with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding integer value). All other bits are ignored.

I'm not entirely familiar with Unix permission's octal format, but using 0o755 didn't raise any exceptions.

---

ps - I also would like it if clang-tools -i 12 installed 12.0.1 instead of the older 12.0.0

[shenxianpeng]

It's my first time installing binary on Windows and it failed...

PS C:\Users\xshen> clang-tools --install 13
Don't have permission to install clang-format-13 to c:\program files\python38.             Try to run with the appropriate permissions.
PS C:\Users\xshen>

[shenxianpeng]

From @2bndy5 in cpp-linter/cpp-linter-action#78

regarding clang-tools-pip

It might be a good idea to create the binaries using .exe suffix (see #11) and a link to the binary that doesn't use the version in the title.

(venv) PS path > clang-tools -i 12
(venv) PS path > ls venv/Scripts
clang-format-12.exe
clang-format.lnk
clang-tidy-12.exe
clang-tidy.lnk

Though, this might cause conflicts if the unspecified directory (-d) is always sys.executable and multiple versions are installed.

[shenxianpeng]

that doesn't use the version in the title.

Do you mean to type clang-format or clang-tidy can execute the clang-format-12.exe or clang-tidy-12.exe?
If multiple versions are installed? which binary should be linked?

If unspecified deriectory(-d) it should be fine because the binary name is different.

PS C:\Users\xshen> clang-tools --install 13
Don't have permission to install clang-format-13 to c:\program files\python38.             Try to run with the appropriate permissions.
PS C:\Users\xshen> clang-tools --install 12
Don't have permission to install clang-format-12 to c:\program files\python38.             Try to run with the appropriate permissions.

[2bndy5]

Do you mean to type clang-format or clang-tidy can execute the clang-format-12.exe or clang-tidy-12.exe?

yes.

If multiple versions are installed? which binary should be linked?

I imagine the last version installed. Does this CLI accept multiple versions (like clang-tools -i 12 -i 13)?

[2bndy5]

Don't have permission to install clang-format-13 to c:\program files\python38.             Try to run with the appropriate permissions.

I didn't get this problem because I run all my python stuff in a venv. This might be a good idea (about using a venv) to add to the readme.

[shenxianpeng]

Does this CLI accept multiple versions (like clang-tools -i 12 -i 13)?

No. to install multiple versions need to run clang-tool -i <version> multiple times. 😃

Tested with venv it works. If possible it should be better to fix the permission problem when the user doesn't use venv.

[2bndy5]

I'm not a fan of downloading and executing scripts that require admin privileges. I'd prefer users activate a venv for ensured security.

[shenxianpeng]

I totally agree. maybe I can install the binary to the user folder like C:\Users\xshen\.clang-tools etc when users do not use venv on Windows.

[2bndy5]

I like that as a default value. The user can specify anything they want if that isn't suitable.

[2bndy5]

So, I've pushed my changes to the pro-revision branch.

I also added the creation of a symlink if the tool was not previously installed. Users can use the new -f switch to force the symlink to overwrite a pre-existing symlink.

I tried using a different default install path on Windows, but it wasn't automatically in the CI's PATH env var:

clang-tools-pip/clang_tools/install.py

Lines 66 to 68 in afa5f57

	# if install_os == "windows":
	# # C:\Users\{username}\AppData\Local\clang-tools
	# return os.path.join(os.getenv("LOCALAPPDATA"), "clang-tools")

Its commented out for now, until we find a more permissive path that is in the PATH env var.

[2bndy5]

Closing this as this was essentially solved by #13