DO NOT MERGE - CMake alternative #250
Conversation
|
Simplified the packaging, this is now a multi-binary package, although not yet useful as i'm still figuring out some stuff. Had to abort the build as it was going in a loop. |
That's been on my wish-list for years now. Nice! |
kinsamanka
force-pushed
the
cmake_test
branch
3 times, most recently
from
99d3b6f to
a108db3
Compare
|
This is almost done. Next step is to convert machinekit-cnc and then fix the armhf* builds. |
- Replaced the old build system without affecting the git history of
the header files. Instead of moving, they are symlinked to the build
directory during configuring
- Reworked and simplified the existing debian packaging. The
libraries are now individually packaged to conform to Debian's
standards. A lot still needs to be done.
- There is no more special RIP builds. The resulting binaries can be
both used for running runtests and later used for installation
CMake version 3.12 and later (Buster ships 3.13) has `FindPython2.cmake`, and `FindPythonInterp.cmake` and `FindPythonLibs.cmake` are deprecated. This patch makes the CMake files forward-compatible by including `FindPython2_local.cmake` in older CMakes, and setting needed variables like the newer scheme.
kinsamanka
force-pushed
the
cmake_test
branch
from
bf6a51f to
8c96148
Compare
kinsamanka
force-pushed
the
cmake_test
branch
from
8c96148 to
4fbba13
Compare
|
armhf builds fine, not yet tested on a real hw though. @zultron ,can you please add |
|
Where are we up to regarding actually implementing CMake? It seems like it's implemented for the most part so far, and we're just waiting for something? |
|
machinekit-cnc needs to be converted too. |
|
@kinsamanka - I'd be willing to poke around on that repo and see if I can make some headway. Is there a compilation doc/readme or is it the common |
|
@kdunn926 At the moment the build process is a bit convoluted. I've found the |
|
@MicroTransactionsMatterToo - After spending a long day on this, I see the convolution you mentioned. 😄 Thanks for the pointers. I'm not a cmake expert by any stretch of the imagination either but it looks like I was able to wrangle a bunch of this into shape on a matching branch here. There's a couple small changes needed to @kinsamanka 's branch to make sure certain header files are available, and this work also assumes a It's not entirely clear to me how to test things short of just compiling and invoking the binaries manually and seeing what happens. Suggestions are welcome. |
|
Super-seeded by #349. |
5 participants
Continuation of #246