cmake: Fix mcuboot build when imgtool is available as binary

[sant0s12]

This commit fixes the mcuboot build when imgtool is installed as a binary. Otherwise, the python interpreter tries to read the binary file and complains about reading null bytes.

[github-actions]

Hello @sant0s12, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[nordicjm]

This is not correct, having imgtool as a binary is not supported (and I'm not even sure how you get it as a binary anyway). Python will install packages without a .py prefix, e.g. /home/user/.local/bin/imgtool

[sant0s12]

@nordicjm When using a nix development environment, imgtool is wrapped as a binary and I'm trying to support this case.

In any case, imgtool should be runnable by itself even if it's not a binary, no? The only time when you would need to explicitly call the python executable is then the file is in the scripts folder.

Please let me know if I'm missing something :)

[nordicjm]

In any case, imgtool should be runnable by itself even if it's not a binary, no? The only time when you would need to explicitly call the python executable is then the file is in the scripts folder.

On windows? I highly doubt it

@nordicjm When using a nix development environment, imgtool is wrapped as a binary and I'm trying to support this case.

This OS is a broken design

[sant0s12]

In any case, imgtool should be runnable by itself even if it's not a binary, no? The only time when you would need to explicitly call the python executable is then the file is in the scripts folder.

On windows? I highly doubt it

Ostensibly yes, although I have no way to test this myself, unfortunately. Perhaps somebody else can find out.

@nordicjm When using a nix development environment, imgtool is wrapped as a binary and I'm trying to support this case.

This OS is a broken design

🤣 That's an interesting take. I must say I enjoy it so far but to each their own.

[nordicjm]

Another issue with this PR is that this drops the zephyr detected version of python and does not supply it, that means if there is no system python installed then this will now fail, and if there is a system version of python but the zephyr version of python is different, this will also fail, likewise if zephyr uses a venv (as the guide suggests) and the requirements for imgtool are installed there, this looks like it will not use that version of python.

I would instead suggest following the zephyr setup guide of using a python venv, and that way a binary build of imgtool is not an issue