Add a CMake generator for target 'alias', removing a binary

[xsacha]

This is the first step in a slightly long path of removing compiled binaries used as part of the build process.
This performs the generation of mkalias and most of this code will be reused to do mkrename et al.

When finished, we will be able to cross-compile entirely without native builds, allowing CMake builds to work directly and as part of other packages and build tools.

See: #249

[fpetrogalli]

Hi @xsacha , thank you for working on this. To my understanding your aim is to simplify the cross compilation process by removing the mk* executables used in the build process.

I fear this is not going to be a small piece of work, that will touch a large part of the cmake configuration.

Because of this, I want to propose you to discuss the approach as an issue before proceeding implementing a solution.

If we agree on the design of your solution, it will be easier to review your code, and it reduces the changes of wasting your time.

Please don't think I am trying to push your work back! I fully support the idea of removing the build executables.

Thank you!

[xsacha]

Yes, indeed. This was the smallest one to replace and should give you an idea of what I am looking to do (I'm not working on replacing anything else yet).

Just wanted something that works and correctly replaces all situations the mk* binary is used so you can see what it would look like.

Obviously some things are harder to do in CMake but the benefit is it works on everything without compiling or dependencies.

[shibatch]

I think it is easier to replace those generators with python scripts.
Is there any reason that you are trying to do everything with cmake?

[xsacha]

The variables exist in CMake and can be used directly. Rather than discovering your python executable, making sure you find python3 instead of python2, writing the variables somewhere python can see them and running the script (as you do now for the binaries too).

I believe it would be easier to maintain the scripts too if they use cmake variables. If they change, the scripts continue to work. CMake is designed to work this way, with configure scripts and #cmakedefine's.

I found that most the code you have in there for mkalias, mkrename can actually be removed and is redundant if you use CMake. With python it would need to remain there.

It might be slightly easier to write initially in python only because it is structured in this way to run it externally. Another benefit of using python would allow the code to be used for build tools other than CMake.
Up to you.

[shibatch]

Please go on.
Make an issue first.

[xsacha]

The issue was #249

[shibatch]

What @fpetrogalli-arm means is that we should discuss detailed design of your change first. Python vs. cmake is one thing. We need to know how cmakelists will look like after your modifications.

[fpetrogalli]

What @fpetrogalli-arm means is that we should discuss detailed design of your change first.

Yes, this is what I meant, and we can use this patch as a practical example.

[...] We need to know how cmakelists will look like after your modifications.

This patch is a good example of what we can expect when converting the mk* tools to cmake. Looking at the code, I am not sure this is the best route to take in removing he executable dependencies.

I am particularly concerned about the way we have to specify things like FUNCLIST. The CMake syntax in this case is not very nice...

@xsacha , would it be possible for you to create also a python version of the patch? I know adding python as a requirement to the build system is requiring more than cmake itself, but I think that:

1. python is available on the majority (if not all) the targets OSes we compile for.
2. python will be easier to maintain/extend than cmake.