First release of the Fortran standard library

Announcements
#31

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.

8 Likes
#32

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.

4 Likes
#33

Readers here and those working on Fortran stdlib may want to take note

  1. Windows OS is preferred greatly for enterprise computing,

  2. 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.

  1. That separate library install packages (say MSIs) be available for each of the compiler toolsets they use, whether IFORT, gfortran, NagFor, etc.

  2. That the installs include
    a. MOD files for their Fortran USE 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.

2 Likes
#34

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.

2 Likes
#35

I use Inno Setup

http://www.jrsoftware.org/isdl.php

1 Like
#36

Is there a plan to parallelize the subroutines/functions in std?

3 Likes
#37

Yes. We have discussed it quite a bit, but have not made plan yet.

1 Like
#38

If std will be parallelized, will it use OpenMP or Coarray?

#39

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.

#40

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.

Parallel programming resources
#41

I think Milan Curcic’s recent book especially focuses on Coarray parallel Fortran (Chapter 7). I do not have it unfortunately and I have not read it yet. Metcalf’s book “Modern Fortran Explained: Incorporating Fortran 2018” is also a comprehensive resource on Coarray Fortran. It is effectively a comprehensible version of the Fortran standard. Intel website also has many examples on Coarrays. There is more, but time is limited.

3 Likes
#42

The fortran-stdlib package is presented in Guru repo (Gentoo user overlay) .

P.S.
There are also some more fortran related packages maintained by me: FoBiS, ford, ftl, gtk-fortran (update is required), opencoarrays, StringiFor.

I currently don’t use packages but I try to check if it’s build and pass tests if available.

Maybe opencoarrays package will be moved to main Gentoo portage tree.

The main Gentoo portage tree provides “Codeblocks + FortranProject plugin” (optionally, up to v1.8) out of the box.

4 Likes
#43

Welcome to the forum, happy to see more package maintainers joining here.

I had to search a bit but found stdlib’s package file here:

I know ebuild files from the easybuild project, an HPC software management system. Is this the same thing?

#44

Yes, that is the mentioned above package for fortran stdlib of Gentoo user repository (guru).

In this case the “.ebuild” is a file used by Gentoo package manager (portage) specifying how package manager should handle the package. It’s not related with HPC software management system.

#45

A side question: what will be the scope of std? My understanding is that std to Fortran is like Boost to C++. Since Fortran’s focus is scientific computing, then std should grow to something like Scipy + Numpy.

#46

Scope

The goal of the Fortran Standard Library is to achieve the following general scope:

  • Utilities (containers, strings, files, OS/environment integration, unit testing & assertions, logging, …)
  • Algorithms (searching and sorting, merging, …)
  • Mathematics (linear algebra, sparse matrices, special functions, fast Fourier transform, random numbers, statistics, ordinary differential equations, numerical integration, optimization, …)

That said, the scope is what the stdlib developers want it to be, and one can contribute code or make suggestions.

2 Likes
#47

It’s also been discussed a few times before, some relevant threads:

1 Like
#48

I’ve created a package for AUR (for Arch linux and related distributions): AUR (en) - fortran_stdlib

4 Likes
#49

Thanks for doing this, some minor comments:

  • I recommend to use python-fypp for the preprocessor since most Python packages are prefixed this way
  • you don’t have the variables MINGW_PREFIX and _realname defined
  • the install prefix should be /usr

Here is a patch:

diff --git a/PKGBUILD b/PKGBUILD
index 181a951..574c86a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -2,7 +2,7 @@
 _fname=stdlib
 pkgname=fortran_${_fname}
 pkgver=0.1.0
-pkgrel=1
+pkgrel=2
 arch=('i686' 'x86_64')
 pkgdesc="Fortran standard library"
 url="https://github.com/fortran-lang/stdlib"
@@ -22,7 +22,7 @@ build() {
 
   FC=gfortran cmake \
     -GNinja \
-    -DCMAKE_INSTALL_PREFIX=${MINGW_PREFIX} \
+    -DCMAKE_INSTALL_PREFIX=/usr \
     -DCMAKE_BUILD_TYPE=Release \
     -B"${_build}"
   cmake --build "${_build}"
@@ -34,5 +34,5 @@ package() {
   DESTDIR="${pkgdir}" \
   cmake --install .
 
-  install -Dm0644 ${srcdir}/${_fname}-${pkgver}/LICENSE ${pkgdir}${MINGW_PREFIX}/share/licenses/${_realname}/LICENSE
+  install -Dm0644 "${srcdir}/${_fname}-${pkgver}/LICENSE" "${pkgdir}/share/licenses/${pkgname}/LICENSE"
 }
#50

thanks! Should I add you as contributor?
I recently had a discussion regarding the python prefix and even though there are some inconsistencies, it seems to be best practice to prefix only python libraries while executables based on python don’t get a prefix