Make support for quadruple precision optional #565
Conversation
- use checks in CMake to automatically determine whether quadruple precision is available - default to values in kind we run from the manual makefile don't want to run checks - skip all tests explicitly referencing the quadruple precision kind parameter - add check for extended double precision (available with GCC)
|
I think the manual makefile is accidentally picking up the fypp preprocessed source files generated the in-tree CMake build. Maybe we should split the workflow for the different builds? |
|
Sorry for the mess with the Makefiles. I wish there would be a way to make this cleaner, but it should be working again now. Bad news is we are going to loose a couple of tests due to #534 in the fpm export with this change. |
- remove EULERS_NUMBER_QP export if quadruple precision is not enabled
There was a problem hiding this comment.
I think this looks good. Left a minor comment that can be fixed by another PR.
I like to think of our CMake build system as temporary, we will eventually generate it from fpm. What changes to fpm would be needed, so that it could (in the future) generate the CMake files in this PR?
Creating CMake files from fpm is actually not that hard, at some point I had put together a version of fpm which could write meson and CMake build files (the branch might still be in my fork). The main issue I encountered at this point was that handling dependencies is not simple, because it was not clear how nested subprojects could be handled reliably in CMake (duplicates in the dependency tree, cyclic dependencies), therefore I never really got the CMake build working for more than a standalone project (see fortran-lang/fpm#69 (comment)). Today, I would try it using generated find-modules and checking for the existence of imported targets, like we are currently doing in stdlib-cmake-example. I got this scaling to 6–7 projects interdependent projects already, and the CMake build files are mostly boilerplate that can be generated automatically or only depends on the variables generated by the Doing this for stdlib additionally requires preprocessor support (fortran-lang/fpm#308, fortran-lang/fpm#78) and potentially optional features (fortran-lang/fpm#609). |
|
Looks good to me to merge. |
|
Just saw I broke the fpm deployment and the manual makefile build on all other branches. I opened a hotfix for this in #567 or we can merge this PR to fix everything up again. Sorry for the mess. |
|
Yes, if this fixes everything, we can just merge this one and close #567. |
|
Let's add a pin for test-drive here as well, while this requires manual updates from time to time, it will help to mitigate similar issues in the future. I'll merge this PR once the CI passes. |
Closes #527
Closes #485
Closes #567