Can fpm build mixed free and fixed form codes in a project?
I’m trying to fpmize BLAS and LAPACK, but both libraries contain both free and fixed form codes.
To simplify the project, in the first step, I separated free and fixed code into different source directories.
source directories
src_blas_fixed
src_blas_free
src_lapack_fixed
src_lapack_free
My plan is to follow these steps to compile them and build libblas.a and liblapack.a utilizing fpm:
steps
Create libblas_fixed.a in the lib directory using fpm install --prefix .
Create libblas_free.a in the lib directory fpm install --prefix .
Combine libblas_fixed.a and libblas_free.a into libblas.a:
ar r lib/libblas.a lib/libblas_fixed.a lib/libblas_free.a
4.-6. same as 1-3 for lapack.
However, when using fpm, it requires modifying fpm.toml file for each step. Here is a part of the fpm.toml file that needs to be modified in each step:
Only recently has the default been to assume all files are free-format by default.
Now, from the manual:
Source form
Allows to specifiy the source form to be used for all files in the
project. Possible choices are "free" to assume all files are free form
source, "fixed" to assume all files are fixed form source, and
"default" to let the compiler decide based on its own heuristics. The
default option is "free".
That is typical of legacy fortran codes that are actively being maintained and developed. The de facto standard, which is already supported by many compilers, is to treat file names *.f and *.F as fixed-source form and to treat *.f90 and *.F90 as free-source form. Is there a flag within fpm to respect that convention, or one similar?
Regarding LAPACK in particular, that library is in a constant development mode. Many versions of that library that are distributed by various vendors are perpetually out of date, making it difficult for application programmers to use the library in efficient and portable ways. If your port of LAPACK to fpm will be like that, perpetually out of date, then that would not be widely useful to the programming community, and it arguably might even be harmful if it involves packaging versions of the code with known (and elsewhere corrected) errors or if it does not include the latest developments within the library. I do not know of a general solution to this problem. How are you addressing this general issue?
The 'source-form=“default” line in the fpm.toml manifest file is the switch. Since version 0.8.0
the defaults are to assume free-format. Allowing “default” behavior leaves it up to the compiler,
which as you mentioned typically assumes “.f” and “.F” are fixed, and “.f90” and “.F90” are free-format. Other suffixes like “.ftn” and “.for” commonly vary between compilers as to what they imply.
Writing perfect code that cannot be improved using a language with perfect upward compatibility that is perpetually available solves the other problem
[build]
auto-executables = true
auto-tests = true
auto-examples = true
# new default with v0.8.0
# force module naming rules to avoid collisions with other packages
#module-naming = true
# traditional where user can use any module name
module-naming = false
# new section with v0.8.0
[fortran]
# assuming code is stylistically "modern" fortran
#implicit-typing = false
#implicit-external = false
#source-form = "free"
# traditional pre-version8 compatibility
implicit-typing = true
implicit-external = true
source-form = "default"
Thanks, @urbanjost! source-form='default' solves my very first problem.
@RonShepard, I’ve started two projects: one for BLAS called forblas and one for LAPACK called forlapack. In both projects, I use the original LAPACK repository on GitHub as a git submodule. This ensures that the LAPACK and BLAS projects under the fpmized project are always up-to-date with the original repository.
Now, on my Linux system, I can compile BLAS and LAPACK using fpm. In a next step, I’m thinking of integrating all tests into fpm for both projects.