CMake Install Module

[theNerd247]

I'm planning on using this library for testing ROS nodes using GTest. I've noticed the current CMake setup doesn't include install targets. Are you planning on adding install targets and CMake module files so find_package(rapidcheck) can be used?

[emil-e]

I do not have any plans to do it currently. I never intended RapidCheck to be used as a shared library so I'm not sure it would make sense to install it. A majority of RapidCheck is implemented as templates so you wouldn't gain much from it.

I always intended for it to be simply included using add_subdirectory and then simply linked against using target_link_library. However, if you have a suggestions or a pull request, we can discuss it.

[theNerd247]

I might work on a pull request within the week or two. The main issue is that I'd like to use it on multiple CMake projects and managing multiple clones of this repo can get tedious. From my experience CMake isn't fond of one including a subdirectory that is not located within the project hierarchy.

I'm a big fan of header libraries (i.e. Eigen) and installing them on a system is easy peasy for CMake. Also, for linux installing static libraries has never been a problem.

[emil-e]

I see, sounds reasonable. Well, if you make a PR for this that looks good, I'll happily merge it!

[theNerd247]

@emil-e Do you plan on doing any versioning of this library? I ask because you weren't planning to have a system install then your versioning is simply controlled by git checkouts. However if you're doing a system install you'll want to prevent dependent packages from breaking because they're using an outdated (or incompatable version) of this project.

[emil-e]

I don't currently have any plans of versioning but it's not ruled out in the future.

[theNerd247]

Ok. I'll add cmake version file later on if you decide to do so. In which case I'll clean up the cmake file from #124 and it should be ready for a code review.

[russel]

Both an install target and a version number make a great deal of sense. I have come new to RapidCheck as I am writing an article on property-based testing and the audience have a strong C++ element, thus I am doing some RapidCheck examples. The standard model is for there to be header files in /usr/include and shared and static libraries in /usr/{lib,lib64,lib32}. People with C++ projects will be making this assumption. Having to do Git submodules (or Mercurial and Bazaar equivalents) and specialist builds as a form of vendoring of the library would work fine in a Go context, but not a C++ one. Rust is somewhat different due to Cargo and the crates. Given there is a CMake build, adding install should be trivial, and, I would suggest, the better way forward for traction. Also it is the way of getting RapidCheck into the Debian and Fedora distribution repositories.

[NAThompson]

Having an idiomatic CMake install target would indeed make this library much easier to use. Would also help with the error messages from CMake.