Revamp CMake configuration to "modern" CMake

[rcurtin]

This issue came about as a result of #2107, which disables Boost's CMake configuration scripts because mlpack's CMake configuration is written in "old-style" CMake.

An introduction to the difference between "old" and "modern" CMake can be found at these resources:

• https://cliutils.gitlab.io/modern-cmake/
• https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
• https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1

The goal of this issue is very wide-ranging: essentially it means completely overhauling mlpack's CMake configuration so that it is done in the style of modern CMake, and will be compatible with future changes to CMake. Specifically, we should be able to remove the hack of #2107 too.

I don't have a set workflow for solving this issue; it will have to be approached by spending a lot of time with the current CMake configuration and understanding its ins and outs. I won't claim that the current CMake configuration is clean either. A definite gotcha is the bindings configurations, in src/mlpack/bindings/*/CMakeLists.txt. These are tricky CMake scripts that do things in strange ways to get the automatic bindings building, and it may be very difficult to port these safely---especially the Python bindings, which have to do a lot of configuration of dependent files and then call out to a different build system (setuptools).

This may be appropriate as a GSoC project, too. 👍

[knakul853]

@rcurtin book is really nice, I found it very broad but something new and challenging

[abernauer]

@rcurtin If you want help establishing a proper workflow for handling the issue open to helping. It's a pretty open ended issue and agree the scope is fitting of a GSoC project. I can write up some documentation on best practices for CMake to help whoever eventually tackles the issue.

[knakul853]

@abernauer that would be great to create a workflow, it will help a lot to start with : /

[birm]

I've added an item to the GSOC ideas list just in case no one gets to this first.

[kumaran-14]

@birm I'd like to work on this as a GSoC project. I have good experience in cmake build system. As a starter, I would like implement a basic c++ project which uses new cmake build features.

[birm]

@kumaran-14 That sounds like a great start! If you haven't already done so, consider joining the mailing list and/or irc: https://www.mlpack.org/community.html

[mlpack-bot]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! 👍

[shubham1206agra]

Is this issue still open or is it done already?

[Aakash-kaushik]

Hey @shubham1206agra I think this issue has been handled but @rcurtin might be able to provide more info on it.

[rcurtin]

Sorry for the slow response. This actually is not yet done, but, note that initiatives like #2646 and #2440 mean that the dependencies of mlpack will change significantly in the near future, and thus the CMake configuration will change somewhat too.

I think, if you are interested in working on this, we should find a way to split up the work into small pieces, since mlpack's CMake configuration is quite complicated due to all the bindings. Maybe starting with the base library/headers (and note that libmlpack.so will be gone soon, since we are making mlpack header-only; see #3091), and making it satisfy each of these things is a good start:

https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1

Anyway, I hope that's helpful---I suspect this effort will get to be kind of in-depth. :)

[shrit]

Also, an idea to add on what @rcurtin mentioned, when mlpack becomes header only, we can inspire from the ensmallen cmake configurations since they are (I think) using modern cmake.