Occa: cmake support

My 2 cents...

Many software packages I employ (e.g., VTK) are configured and built using cmake, but I for one dislike it. Not so much for the cmake language and code one has to write, but rather for the very obscure makefile "components" it generates into a deep and obfuscated directory structure. So figuring out why cmake is failing, or why something is not compiling right, or how to tweak a build, can be a non-trivial effort (for me at least).

Generating a makefile for the current build environment per configuration specs is generally a good thing, but whatever the generator may be, should IMHO generate only a single, flat, straightforward makefile that is read-able and potentially tweak-able (like venerable 'configure' does). That sure isn't cmake!

Hi Paul,

I'm not in love with it but once installed in a project it is pretty solid. The major advantage of it is integration and testing. For instance - suppose - I'd start integrating OCCA into a rather large code, I would put the source into a directory called 3rdparty, and, if it was using cmake I would just tell cmake of the new directory add_directory(...). Then it would build OCCA automatically, using the compilers and other specs from the "top" CMakeLists.txt. If I added dependencies to OCCA in a test driver (initially) and to more source/other directories later it would be a breeze.

My experience with cmake, is that if you have problems at the "make" level, usually the problem is that you've specialized too much (eg. force explicit compiler flags...) cmake at the top level. For most problems make VERBOSE=1 will reveal the full compile line (which you can cut & paste) to figure out what is wrong (& then change the cmake (not the make)).

We also use ctest all the time...

Anyhow, just wanted to test the waters regarding this.

Best,

Amik

I'm a fan of it (maybe too much so), in fact, CMake support is the first thing I looked for. I manage all dependencies (for example in GooFit) as git submodules in extern, and then CMake will check those out for the user if they don't know about submodules, then CMake combines all the dependencies. The great thing about CMake is it supports any way of working - if I want to use an IDE, for example, like Xcode, it's easy only if CMake is used. I can add CCache, debug builds, clang-tidy, etc. quite easily.

@henryiii If it has IDE integration, that sounds like a good idea!

I'm hesitant to remove the Makefile build since make can be found out of the box in most places, but we can add CMake support alongside it. We can update the CI config to run tests with both make and cmake builds.

If you have time, can you make a PR for it with the core CMake files? If it helps, I can add all of the environment variables / side effects that are expected during build time

Right now, new / prospective OCCA users (HPC programmers) just need to download OCCA source, and type make. Very simple. To me, the OCCA value proposition is based 100% on the outstanding features it provides in the parallel programming domain, not in its build system. Nevertheless, maybe there would be a small value-add for OCCA to move to cmake-based builds, I don't know.

Perhaps someone knowledgeable in cmake coding could write the requisite cmake files and contribute them to OCCA via a pull request? That might help satisfy the concerns some folks seem to have and help them move on to actually use OCCA.

Back on the subject of cmake, for some of us anyway, "mileage may vary." Seriously, I am sure my enthusiasm for cmake would elevate greatly if I actually learned how to write / debug / modify cmake language code at a level beyond my current pre-newbie stage. In the meantime, when I encounter frustrating problems with someone's poorly written / out-of-date CMakeLists.txt and/or buggy or poorly written Find*.cmake files working properly for some package I've just downloaded from github for evaluation, I can have unpleasant sensations of negative appreciation!

@pdhahn Just to be clear, I don't think I would ever get rid of the "only type make to compile" build. Definitely needs cleaning up (#149) but making installation and usage simple for users is the number one priority here

Adding CMake would help use OCCA in projects that already use CMake and it looks like make developer lives easier with this IDE integration.

@dmed256 You are right, the IDE thing does sound like it could be a non-trivial value add for OCCA!

But you need to accommodate a variety of popular IDE's at a minimum, like eclipse and Qt Creator.

CMake supports all sorts of tools (and all sorts of tools support it), not just IDEs. All major IDEs either are supported by CMake or CMake supports them. CLion, Qt Creator, Eclipe, Xcode, and more. It also supports link-what-you-use, include-what-you-use, clang-tidy, ccache, various test integrations, packaging, and more.

If the CMake build worked well, you can eventually have the Makefile simply call CMake for you, I've done that before in GooFit. You might even have the makefile download CMake and then call it (I haven't tried that before, but I think I've talked to someone who has); this would allow it to work anywhere and with the latest version (you'd just need to have a simple toggle that downloaded the linux or macos binary depending on where you were running).

I'm hoping to evaluate occa in the next couple of weeks, and then might be able to help with CMake support.

@henryiii That makes sense, we only have so much time :) Regardless, appreciate that CMake advice!

Closing thanks to all of the work from @hknibbe2, @SFrijters, @amikstcyr, and @JamesEggleton 🎉