As @zoziha mentions
in Who is using stdlib? - #8 by zoziha
, you can use stdlib as an external library and there is already
a version of stdlib that breaks it into subsections by @degawa
at GitHub - degawa/stdlib_modules: Provides each Fortran stdlib module as an individual fpm project that explores how this
might work. I have maintained a large library at
GitHub - urbanjost/general-purpose-fortran: General Purpose Fortran Cooperative that I generally
also make major components of into individual fpm repositories so I
can say there are pros and cons.
-
being able to build and use individual modules allows for making
individual releases of such with their own documentation and testing
which is particularly appealing when the overall package is frequently
changing as something like stdlib is/will be doing. -
it can create a large amount of duplication if you want the modules
to truly be independent packages, or you have to require a build to
build other packages, risking descending into “dependency hell”. -
build times are minimized
and so on. Some of the other possible solutions to selectively build
only routines used works better with non-modularized procedures but does
not buy much with modules without something quite elaborate in place to
only build sections of modules.
There are a lot of arguments along the way but my general conclusion is
binary releases for several major compilers as agnostic packages (no CMake,
fpm, make, …) covers a lot of users and usage as most users are not using
more than a few compilers (often one).
Then, a expanded source version, possibly built for each compiler, possibly
still containing “almost defacto” fpp preprocessing directives. A makefile
for the release would be preferred.
For those who want to build themselves or capture and incorporate the
code I think focusing on fpm is the better alternative, but it needs
to be able to use a pre-built fpm package more easily without having to
install the components as a conventional external library, and needs the
profile for a “shared” build to be able to be specified. I picture this
as an area you specify for fpm packages that you can point to and your
builds will use the “standard” build profile for a compiler to build
it once and other packages can then link to that build in the project’s
build directory in a read-only mode, with an option in the fpm.toml file
to use a specific profile build.
Ultimately, something stdlib-compatible will be supplied with compiler
distributions, but these are some ideas on how it could evolve in the
mean time.
In general I think a lot of users just want to be able to use stdlib as a “product” and install compiler-specific versions in subdirectories they can point to; others want the source free of having to pull down a lot of infrastructure to incorporate in their code or to examine and extract routines from without learning about github and git and fypp and …; and the last major group wants an efficient way to maintain large projects in fpm.