Make the CMake examples be independent projects

[LecrisUT]

Make the CMake examples be independent projects showing how the user project should look like. These projects are also added to the testsuite.

However, the tests cannot be run right now because the example projects have expected failing tests, for which we need a way to run each test case individually and specify how those tests are expected to fail.

This is part of #41

[aradi]

Stupid question, but please help me to learn 😉 : What is the point of having the basic package version file and package config file outside of the install guard?

[aradi]

Yes, in general I'd prefer to have separate ones (sorry!), as I find it easier to discuss about specific single topics as about too many at the same time.

[aradi]

Based on experiences with former projects, I think it would be worth to keep examples and tests separately for didactical purposes:

• examples are best practice code demos (which we could/should probably test as well, I agree), to be used by users when they start to use the library.
• tests can be anything needed to test certain functionality of the project. They must not be neither meaningful nor useful for users.

If we mix the two by putting everything under tests, first time users would be either confused and not finding the place to start or grabbing something, which was for internal testing only and not meant to be used by consumers of the library.

By the way, Fortran projects created with fpm --full also have both, a test and an example directory, so it might become a common pattern in the Fortran world.

[aradi]

Oh, now, I see how you did that with symlinks. OK, that could be reasonable solution. When one turns the examples into individual projects (which probably indeed makes a lot of more sense), then the export test would be superfluous, which was testing whether the compiled library can be used.

[LecrisUT]

Stupid question, but please help me to learn 😉 : What is the point of having the basic package version file and package config file outside of the install guard?

Yeah, this is one thing that I didn't understood until recently.

• The configure_package_config_file and such are just fancy versions of configure_file which generates the file (FortunoConfig.cmake) and puts it in the build_dir. And in the definition it tries to look for a FortunoTargets.cmake file right next to it
• install(EXPORT) does not generate the FortunoTargets.cmake in build_dir, only in the install prefix
• export(EXPORT) generates the FortunoTargets.cmake in the build_dir (with the context of the build targets, instead of the installed ones, e.g. target_include_directories will evaluate the $<BUILD_INTERFACE> instead of the $<INSTALL_INTERFACE>)

As for why we would need the FortunoConfig.cmake file in the build_dir, it's for running the tests without needing to run the install step

Yes, in general I'd prefer to have separate ones (sorry!), as I find it easier to discuss about specific single topics as about too many at the same time.

NP, this part is relatively self-contained to making the examples as independent projects, I'll split off the description and make it an issue.

When one turns the examples into individual projects (which probably indeed makes a lot of more sense), then the export test would be superfluous, which was testing whether the compiled library can be used.

Yes, I was suspecting that that was the case. We still need them for now, because the running of the current example tests is disabled because they seem to fail by design. We can probably mark the relevant tests with WILL_FAIL or PASS_REGEX, but we need to split the tests to run individual tests and select which ones are meant to fail.