Proposal: remove fypp dependency from stdlib

Fortran is in a tough spot regarding preprocessing. It doesn’t have generic programming, so pre-processing is sometimes needed (particularly when writing libraries), but there’s no standardized preprocessor - so everyone just uses whatever they personally like the best.

There are many options out there in the wild with different strengths and weaknesses. I don’t think that fypp is bad, but I do wish that stdlib was completely self-contained. As it is, fypp and therefore Python are required in order to build it. In the interest of making stdlib self-contained, would there be any willingness to move away from fypp for stdlib, and towards a different pre-processor that is written in fortran and directly packaged in the stdlib repository? That way, the only thing needed to build it is a fortran compiler (which anybody using stdlib must have anyways).

I would strongly prefer making this change, and I don’t care what that hypothetical preprocessor is. While I’m sure there are others, I’m aware than @urbanjost has written one under a permissive license A streamlined preprocessor written in Fortran . I personally have no vested interest in using this one or another one, but I do think we are better off by making stdlib self-contained, requiring only a Fortran compiler.

Doing this would also give us the opportunity to solve another problem that stdlib must eventually fix. Since Fortran permits different processors to implement different kinds, the only way to offer a generic library that supports every data type that the underlying compiler supports is to query real_kinds, integer_kinds, etc, and generate code accordingly. If we move to a preprocessor written in Fortran, we can fold the _kinds checks into the preprocessing step. For example, gfortran supports real(kind=10) on x86 - it’s the x87 80 bit floating point implementation. But the intel compiler does not support it - if we want to support it in stdlib, then we need to generate extra routines for kind=10 at build time. A preprocessor written in Fortran could both figure this out AND generate the code.


First of all, you don’t need Python to build stdlib. Just use the stdlib-fpm branch which is automatically generated. If you depend on stdlib using fpm, that is what will happen. Currently we don’t have releases for stdlib, but once we do, we would distribute tarballs that are preprocessed, so no Python dependency. Update: I should clarify that there are no Python dependencies for end users. However, if you want to develop stdlib and send patches to it, then you unfortunately need Python.

For your other points, see also this thread:


Fair points, but even on the branch that doesn’t require fypp, the issue with supporting multiple kinds remains, though. The only way to know which kinds a compiler supports is to ask the compiler. So while we can render out versions that work with FPM and don’t require preprocessing, those releases may not work with all compilers, or may be missing kinds that the compiler supports.

It may not seem like a big deal right now when most work is done with the default real kind or with double precision, but once compilers start supporting 16 bit float, it’s going to start to matter a lot for some applications.

Implementing preprocessor functionality in FPM sounds like a good idea at first glance, but I’m not sure if we want to force users building stdlib to use FPM… do we?


We would make the preprocessor a separate package so while fpm could automatically call it, you can also use it separate. Isn’t that exactly what you are proposing, to have the preprocessor implemented in Fortran?


The root cause of this problem is that Fortran lacks sufficient syntax to support multiple precision, multiple types, and indefinite array dimensions.
So we use fypp to achieve this goal, even this solution is not perfect (see Data-mining: stdlib build error with fpm (macOS Apple Silicon)), we can only look forward to the birth of Fortran corresponding syntax. ( Rank-agnostic array element and section denotation and j3-fortran/generics (
During the development of stdlib, these issues are worthy of feedback to the Fortran committee. I believe that the development of stdlib symbolizes the feasibility of a universal (precision, type, and dimension) Fortran algorithm library.