How to make ARPACK fit into the fpm-universe?

Hi all, long time no see :slight_smile:

I have been quite busy lately with a research project, but I’m slowly entering again a development stage, so I’m trying to catch up with all the (gorgeous!) updated to the fortran package manager.
If I got it correctly, as of today, fpm can natively include minpack as a metapackage (along openmpi, stlib…), and I find this very nice and useful!

So… How are the bets on obtaining that for arpack too?

I currently have a fpm-ized version of ARPACK and PARPACK that succesfully compiles, but with custom flags (the deafault -Werror is really too much, as Arpack source indeed rises warnings).

On this respect I’d avoid entering a full “modernization” effort, as mentioned in this another thread Modernizing Arpack, cause ARPACK is huge and generally I think the community trust it quite enough, to avoid important rewritings.

If I didn’t miss something, there’s no way to enforce package-bound flags, so anyone wanting to include this fpm-ized ARPACK library would need to pass the flags explicitly, which is in my honest opinion annoying enough to hinder adoption: people might want to use the default flags for their project, or other different custom set, and not being forced to adopt the flags ARPACK would require (and declare in its README, I guess).

I see two ways out of this:

  1. A way to enforce flags for a library (but it might be difficult for the general case, and there are other problems involved with arpack. E.g. not having a modular structure, so not being able to conform with the name conventions, etc.)

  2. Treat ARPACK as a famous-enough legacy package, and provide it natively as a metapackage.

What do you think?


Let’s modernize arpack-ng!

1 Like

It would be great if somebody had time to push this over the finish line: Compiler flags profiles by kubajj · Pull Request #498 · fortran-lang/fpm · GitHub

Just my 2-cents.