Fix packaging for Fedora 35 and address various other packaging issues

Issue/feature addressed

This MR addresses issue #281 (closed). It also supersedes MR !1313 (closed). The focus of this MR is to remove the outdated Fedora 33/34 distros from the packaging pipeline and to add Fedora 35. In the process of doing this, a number of issues were encountered. These were additionally being addressed via !1313 (closed) but since the source merge branch for this MR did not have a "pkg/" prefix, the packaging stages of the pipeline were not being run. As such, a new MR is now being created to finalise these changes and ensure that the correct pipeline stages are run as part of the testing process.

Proposed solution

The original Fedora 33/34 packaging configuration has been removed. A new Fedora 35 config, based on the previous versions, has been added. Other changes to the Nektar++ code/configuration resulted in errors with the packaging process on Centos 7/8 and on Fedora 35 when building the documentation. These issues have been resolved. A final issue was encountered with Fedora 35 due to one of the third party packages being used - OpenCASCADE - and a fix for this has now been implemented.

Implementation

The packaging configuration follows the standard setup used for previous Fedora 34/35 packaging. Some packages had to be added to the texlive package installation process on Centos 7/8 which is configured to use texlive's package manage tlmgr and on fedora35 which is using regular OS packages to provide additional texlive modules.

A more substantial issue was encountered with the way the Nektar++Config.cmake file is generated on Fedora 35. This file is used by other code that leverages and is built against the Nektar++ libraries.

The process of building third-party code that utilises Nektar++'s libraries is tested by trying to build the ExampleSolver.cpp solver by running the templates\executable\test.sh script in the Package-test CI phase. This uses CMake to build the code, specifying Nektar++ as a dependency. In turn, this uses the Nektar++Config.cmake file to get details of all the various headers and libraries and any other configuration to link in as part of the build. Since Nektar++ depends on a range of other libraries, the Nektar++ cmake configuration also includes build configuration from these other libraries. In the case of OpenCASCADE on Fedora 35, which is installed via the F35 packages, the cmake configuration that is pulled in when Nektar++ is originally configured and built includes some CMake generator expressions. These were not being correctly processed resulting in raw generator expressions being included in the Nektar++CMake.config file. This, in turn, was causing the CMake configuration process to fail. Various approaches to resolving this were considered. An initial workaround that was tried simply modified the current conditional in the definition list generation which ignores VTK-related flags, extending this to also ignore any attempt to add generator expressions to the defintion list. This was not an optimal long-term solution so a more robust solution is being committed in this final version.

Initially, the generator expressions included in the NEKTAR_DEFINTIONS parameter were not being processed at all. Adding a CMake FILE(GENERATE ...) call resolves this but, when a generator expression resolves to an empty string, as the expressions being pulled in from OCC do with our current build configuration, the definition list ends up with a number of empty -D flags. This has been resolved by using an IF generator expression to check whether a definition (represented by the def variable) is empty. If def is empty, we need to convert it to a true/false value using BOOL so that the if expression correctly handles it. Previously the defintiion list was generated by simply creating a space separated string, however, this is not processed correctly by the various expressions and results in lots of semi-colons in the output. Instead, we now separate values with a semi-colon explicitly, identifying them as a CMake list. We then use JOIN to join the list items into a string with space as the separator. This finally results in a valid definition list when FILE(GENERATE ...) is called to evaluated the multiple nested generator expressions.

Tests

This is not applicable in the context of this MR - the existing packaging pipeline runs these changes and a new set of fedora 35 jobs have been added to the pipeline.

Notes

There is still a known issue with this update based on the handling of generator expressions in CMake configurations pulled in from third party dependencies. This will need to be resolved going forward but it is not currently a critical issue since Fedora 35 is the only platform on which this has been encountered so far.

Checklist

• (N/A) Functions and classes, or changes to them, are documented.
• (N/A) User guide/documentation is updated.
• Changelog is updated.
• Suitable tests added for new functionality.
• (N/A) Contributed code is correctly formatted. (See the contributing guidelines).
• (N/A) License added to any new files.
• No extraneous files have been added (e.g. compiler output or test data files).