A few questions about SciFortran and it's packaging about scifortran HOT 3 CLOSED

Is arpack-ng (instead of arpack) used really?

Yes, look at the log of commit 8e1d8cd for some clarification in this regard. I'm not sure about the other libraries though. I mean yes, currently they are built from source together with our modules, but I don't know if they are untouched wrt the original releases and if we could want to unbundle them to rely on external linking. Without exact version management it could easily become a maintenance nightmare. Probably if we ever switch¹ to the Fortran Package Manager (which hasn't got the the 1.0 version yet) and those packages move too we could start considering it.

Names and directories structure convention

I don't really know if there's even more rationale, but for sure we are quite a bit constrained by HPC environments (where SciFortran is ran the most, as far as I'm aware). Therein users have no root privileges and so access to those directories can be problematic. That's why everything is under ~/ and we provide an easy interface to Environment Modules.

Release circle: could it be less often, with accumulation of several fixes and features?

Mmm, I'd say not, for similar reasons of the above: we rely a lot on git tags to identify which version we are running on the HPC environment (basically the modules have the form scifor/platform/tag). That's why every single bugfix / feature is tagged. We are DevOps and we need to run / test easily the latest version on master quite often, nevertheless maintaining the possibility to roll-back of one or two commits if something breaks our computations.

Many places of scifor project store version number and it's frozen at 4.7.3

Yes you are right that this has to be avoided. I recently (03228bc) deleted the SET(VERSION X.Y.Z) line in the top-level CMakeLists file, as it is superfluous (again, we rely on git tags). If other spurious version numbers would be found similar action would be taken.

Documentation, examples, tests

You are totally right here. Some testing has been recently set up (d62d0ce) in a tentative workflow. We plan to greatly expand the test suite in the forthcoming months. We plan to set up a continuous delivery workflow too, aimed at automated generation and web deployment of an API documentation. This has already been done for our new library, HoneyTools. Here there is much more work to do, as SciFortran is extensive and source comments are a lot less uniform (given the long-lived development and the great amount of legacy code), but we are working on that. :)

from scifortran.

About libraries:

Well actually only ARPACK¹ seems to be missing from the fpm stack...

• FFTPACK: https://github.com/fortran-lang/fftpack (but is based on original v4.0, while we are embedding v5.1)

• MINPACK: https://github.com/fortran-lang/minpack (don't know about version [mis]match)

• QUADPACK: https://github.com/jacobwilliams/quadpack (idem)

from scifortran.

Brief update: API docs generation has been introduced in commit b22ff66, you can inspect the output for the latest version on master at https://qcmplab.github.io/SciFortran or build a local version for any later commit/tag by running ford docs.config in the root of the repository.

from scifortran.