Make librascal easier to use in external project

[Luthaf]

I'm opening this issue after discussions with @gtribello about the integration of librascal with PLUMED.

For completeness, PLUMED is using autotools, so all of the cmake facilities (target_include_directories, ...) are not available, and we have to use CPPFLAGS/LDFLAGS directly.

We have identified multiple issues with the current way librascal is built and installed that we should resolve:

• [ ] make install does no install headers, only the Python bindings & shared library.
• [ ] using SphericalInvariant calculator requires the user to manually link to wigxjpf. Ideally, libwigxjpf.a should be directly included inside librascal.so, so that linking librascal brings in all required symbols. In the same idea, the wigxjpf headers should be installed somewhere available, for example inside PREFIX/include/rascal/.
• [ ] there is no easy way to build librascal as a static library. While we need a shared library for the python bindings, having a static library can also be more convenient when redistributing/executing the final executable/library

[Luthaf]

I think the ideal workflow for users would be

1. configure librascal with cmake
2. make install
3. integrate librascal with your project a) you are already using cmake: just pop a find_package(rascal) in your CMakeLists.txt, then target_link_libraries(my_target rascal) and everything works b) you are not using cmake: set CXXFLAGS to -std=c++14 -I$PREFIX/include and LDFLAGS to -L$PREFIX/lib -lrascal

We could also distribute a pkg-config file to automate case 3.b).

[max-veit]

Just chiming in to say wigxjpf should not be required for the basic SOAP power spectrum. Maybe we want a way to compile without it, e.g. separate out the power-spectrum code from the higher-body-order stuff?

+1 for pkg-config and static library.

[felixmusil]

I made a few modifications to the cmake configurations to allow for external integration in feat/improve_integration_as_external. You might want to have look there too.

[Luthaf]

We found out about issue #335 while working on this, and forcing an external project to change their own compilation flags is not a good practice. They could configure rascal with -DTYPE_ARCHITECTURE=x86-64, but this is not documented anywhere, and makes it harder for end user to build everything (since they now need special instructions for building librascal for integration in a separate project).