Is there a timeline to replace fypp with a pure-Fortran implementation?
I donāt think anybody is working on this yet. Do you want to help?
Many libraries for scientific/engineering applications donāt work well on Windows because it is not particularly suited for number crunching. C libraries have at least the advantage that cross-compiling is simple and pre-build DLLs can be used (FFTW is doing that, FFTW Installation on Windows) but for the actual installation one usually tries to make Windows behave like Linux/Unix (see also Installing PETSc On Microsoft Windows ā PETSc 3.20.1 documentation).
What would be the benefit? Fortran is good for number crunching, other languages are good at text processing.
That you can just download one binary of fpm
on any platform (say Windows) and it will just work with stdlib. No need to setup Python, Conda and fypp.
ah, Windows problems
Yes. But Windows is just a symptom. The underlying problem is that from an engineering perspective, it is more robust to stick to just one technology, in our case Fortran, as thatās what fpm
is written in. It could also be C++ (because we need a Fortran compiler anyway, and Fortran compilers work well with a C compiler and C compilers today mostly ship with a C++ compiler also). But Python is tough from the distribution point of view, not just on Windows, but Windows is the most obvious.
If we could have a pure-Fortran preprocessor, that would be great. Most of my colleagues only use R, Matlab, and Fortran. We strongly prefer one-based indexing programming languages and never consider Python. Thatās why the fypp file really confuses me. To be honest, I donāt understand them at all.
Since I donāt write Fortran packages and only deal with integers and doubles, generics are not important to me, either.
See this post, my comment and Certikās followup comment.
agreed. My technology is called āpackage managerā. It allows to rely on existing software independently of the used programming language. I know that this is not common on Windows and MacOS and there are also issues on Linux. That is why Conda and pip are popular. But overall, it is the best approach Iāve encoutered so far.
But Iām not a missionary, if someone is interested in writing fypp in Fortran itās fine with me. It just feels like writing a large-scale numerical solver in bash, using Windows for numerical simulations, or Linux for gaming.
Some feedback from a Windows user:
I work for a fairly large Engineering and Manufacturing company, we create a lot of dedicated software for our own use, using Fortran and Matlab. The company policy is to use Windows only and most of us use Visual Studio for programming, almost no command line use at all. For us to use the standard library we want to download it and double click on the icon to install.
I do not know if Windows users are in the minority but almost the only thing I see here is Linux, I did not even know there was such a big number of Linux users. So either Windows users are a small group or they are not participating.
Well and not just the standard library, but I would assume you want to install any Fortran library this way. It is my goal with fpm to make it create such installers for any fpm package, including the standard library.
My experience from 10 years ago was that Windows users were the majority of users, but also the minority of developers, and the minority of participants.
I donāt know if it has changed too much since then.
Absolutely. Currently there is only one cross platform package manager that has reasonable usage and is reasonably simple to install and works well with whatever local setup you have. And that is Conda. And we use Conda, fpm and fypp is there too. And if you use Conda, then indeed this issue is pretty much fixed, just conda install fpm fypp
.
However, not everybody is using Conda. Above you have one example from @Neels, I donāt think they use Conda. Of coure, for their use case, they can just use the release tarball that does not require fypp (or later they can use some installer that fpm will produce). However, we would like them to also be able to contribute fixes back to stdlib. And for that they need fypp.
Sticking to Fortran, and if needed to C and C++, especially if we can figure out how to compile C and C++ with fpm (we are quite close), so that for example all of LFortran builds as an fpm package, would go a long way. Then all we need to do is add backends to fpm to create Windows installers, and cmake, meson, etc. build files (that do not depend on fpm), and we will be in a really good shape distribution wise.
Readers here and those working on Fortran stdlib
may want to take note
-
Windows OS is preferred greatly for enterprise computing,
-
In the enterprise computing domain, the consumers who are driven by their enterprise needs and company work practices, would very much prefer (and perhaps demand even) that for Fortran standard library, āOfficial Releaseā (a la Gold standard per the terminology per some commercial software companies) versions of compiled and optimized dynamic-link libraries i.e., DLLs compatible with particular Windows OS releases per Microsoft (currently Windows 10 and maybe soon Windows 11) be simply available for download and install, ideally in Microsoft Windows Installer format.
-
That separate library install packages (say MSIs) be available for each of the compiler toolsets they use, whether IFORT, gfortran, NagFor, etc.
-
That the installs include
a. MOD files for their FortranUSE
statements,
b. LIB files for linker input on Windows OS,
c. DLL files for run-time,
A go-by for this will be what Intel does with their library support on Windows OS e.g., MKL.
At a high-level, this is not all that different from *UX OS, only that the users of Windows OS - given their base in enterprise environs - are effectively steered toward installing built, packaged, and validated āgoodsā rather than being able to do their own building, packaging, validation, and deployment.
I opened an issue at the repository to continue the discussion on Windows installers:
If anyone here has experience with creating Windows installers, please let us know.
I use Inno Setup
Is there a plan to parallelize the subroutines/functions in std?
Yes. We have discussed it quite a bit, but have not made plan yet.
If std will be parallelized, will it use OpenMP or Coarray?
We donāt know yet. Which algorithms are you personally interested in? We can have a look and start the project. We can also use do concurrent
.
I donāt use the std but want to improve my Fortran skills by reading the std codes. I am currently learning Fortran parallel computing, are there any learning materials that comprehensively introduce using OpenMP, OpenACC, and Coarray with Fortran? Maybe a tutorial on parallel computing can be added to the fortran-lang.org website.