IN PROGRESS - CMake alternative

[kdunn926]

This is the complement to the work here: machinekit/machinekit-hal#250

CMakeLists files have been created for nearly every subfolder so far, with the exception of the /tcl stuff and the i18n (/po) portion still needs to be done.

[cerna]

@kdunn926,
I don't want to sound like a grouch, but DO NOT translate old kernel thread (which were not yet purged from makefile/autoconfig) into new build system.

[kdunn926]

@cerna - No offense taken at all. I actually paused work on this in anticipation I would get valuable input like this, better clarifying where I should focus efforts. Feel free to nitpick in any other obvious places or make suggestions about an "outline sketch" of how you'd like to see this work done.

[cerna]

@kdunn926,
I have (pretty much) just merged pull request machinekit/machinekit-hal#227 into the Machinekit-HAL repository which removed most of the old kernel build from that repository. It was originally opened as a pull request machinekit/machinekit#1462, so now I have to create a pull request which will transport the CNC part from the original pull request into this repository. Ideally, there should be only one Machinekit-CNC package, flavour neutral.

Also, this repository was created from the old machinekit/machinekit repository, the same as a Machinekit-HAL. And from this many thing (not just in) build system stayed which now are unneeded or otherwise wrong. Everyone just hackled on it to get his feature to work with minimal work possible. One of the reasons why nobody created some modern build system is because of this, it will require some detective work to see what's needed and what to toss.

I will have to look at your solution in more detail - problem is, I don't have deep knowledge about CMAKE, so I don't know if I will be much help. It would be nice to have as much encapsulation of given parts as possible into somewhat independent modules. Also, and here I don't know, maybe to utilize the CPACK to prepare for creating RPM packages and making the life easier?

[kdunn926]

@cerna - That's helpful to know.

To be frank, I'm no CMake expert myself - though I am confident I can [learn to] whip it into whatever shape yourself and others in the MK community want. I am also very much new to this project and have only used MK in a very superficial capacity thus far - I am motived to contribute nonetheless. Given that fact, I have limited understanding of the different components within the codebase, especially as far as what's leftover from the initial fork, duplicated within the Hal repo, etc.

All I need is high-level direction / preferences about logical grouping of things / naming conventions / install targets - I can sort out the "how" part with respect to CMake files and whatnot. What is also very helpful is input like: "this file/dir/set of compile options should be deleted" - in line with your first comment.

[cerna]

@kdunn926,

(...)I can [learn to] whip it into whatever(...)

Yeah, I think that this is probably the best approach. Learn something new and do the work in the process.

I have created a new pull request (#95) which merges-in the single-module changes, so now the Machinekit-CNC can be build on top of Machinekit-HAL HEAD. (It's pretty convoluted and so far pretty much the only way how to do it is to use the build_with_cnc script from Machinekit-HAL or do similar steps manually.) I think I removed the most of the flavour specific build and KERNEL build, but I very probably did some mistakes and introduces some bugs or just oversaw something, so it will need additional polishing. But it should work.

I see the Machinekit-CNC mostly as an out-of-tree build of modules (with some own functionality) for Machinekit-HAL. For example how now the headers are sourced (first they are copied from Machinekit-HAL into /fakeinclude folder, then in subfolders where these headers are needed are dangling symlinks to this /fakeinclude folder, on build the Submakefile in these subfolders copies header files into /include folder -> so basically copies symlink), I call this Machinekit Symlink Hell. Similar with the shared libraries needed for linking against, but I think there it is simpler with just copying them into /fakelibs and there being already CV-controlled dangling symlinks in /lib.

So I have been thinking if it could not be done prettier (and saner too) in CMAKE? Like to have module which is dependent on some other module in Machinekit-HAL from which it will take headers and shared libraries. (Basically if CMAKE has some intelligent support for out of tree build?) Because Machinekit-CNC will (probably) always depend on Machinekit-HAL. The only time it will be used/compiled without (all of) Machinekit-HAL is to create package, I think.