beddalumia
commented
2 years ago Is arpack-ng (instead of arpack) used really?
Yes, look at the log of commit 8e1d8cdb60f05be122f8c35faf248b262796b22b 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.
[^*]: We plan to start supporting it, as an alternative to CMake, but I find quite unlikely a full switch in the foreseeable future.
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 (03228bcdf93859d31417c0df6038b5daa04e51a7) 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 (d62d0ce0ff7633fe07d6c734ee31878a75fc9439) 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. :)
On trying linux packaging of SciFortran a few questions can be interesting to maintainers (+ user repos). I'm trying to summurize some of them.
Third-party libraries (arpack, fftpack, minipack, quadpack): are modified versions of them are used (except cmake-files)? Is it possible to unbundle it and use upstream system installed package? Is arpack-ng (instead of arpack) is used really?
Names and directories structure convention: as I could see the installation directory structure currently aimed to install into user (non-system) environment, isn't? The current CMakeLists.txt and additional .sh scripts look to be aimed for this purpose.
As example the recommended path where pkg-config searches packages .pc files is
/usr/lib/pkgconfig/or/usr/share/pkgconfig/and library path/usr/lib/(the/usr/lib64/paths could be used instead of/usr/lib/in some distributives of amd64/x86_64 arch - but it's easy to patch in place on packaging). Modules could be placed into/usr/include/scifor. Under actively enchancement process of CMakeLists.txt it's easily currently in my case (for gentoo) to skip cmake install phase and force to direct installation of .so library, .pc file and modules to approriate ststem directories.Release circle: could it be less often, with accumulation of several fixes and features? Many places of scifor project store version number and it's frozen at 4.7.3 - it will be easier to change it once on separate "release commit" etc.
Documentation, examples, tests: the documentation writing is very time-consuming process. The examples are easier to create (but still require time) and could be used for tests later. The support of scifor users with examples could be helpful and is welcome :)
The examples could be even made on the base of scipy documentation. The good starting point is creation of structured list of implemented procedures and functions.