Add support for non-default location of MPI for configure

[mmuetzel]

Pull request purpose

Currently, there are no dedicated flags that would point the configure script to an implementation of MPI that is installed at a non-default prefix. (See #479.)

Detailed changes proposed in this pull request

Add support for the optional configure flags --with-mpi-includedir and --with-mpi-libdir to select a non-default installation location of MPI. Additionally, support setting the prefix of the MPI installation with --enable-mpi=PREFIX.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[mmuetzel]

These flags have previously been prepended directly to FFLAGS, FCFLAGS, and CPPFLAGS.
For the changes here, it made sense to collect the corresponding flags in MPI_CPPFLAGS (to avoid replicating the same thing in multiple places).

With that, it would be possible to only use these flags for the library that needs them.

Should this be done?

[fghoussen]

Could you add dedicated tests for this? Like apt-get source openmpi, build-from-source mpi and install it in some /opt-or-tmp/mpi directory and build / run arpack test suite? (mpi is a small lib so building it should be OK)

I would understand 101% this work would be above what you intended to do: i.e. adding some kind of ubuntu_latest_autotools_custom_mpi test in the CI.

I would understand 201% you would not consider adding a second test for the same purpose but using cmake: i.e. adding some kind of ubuntu_latest_cmake_custom_mpi test in the CI.

I understand / agree on the need / PR. But, ideally, I'd like this to be tested!... With both cmake and autotools as we try to get them both in sync and having the same level of functionality.

I'd like to avoid blind pushing: we had lots of never ending and re-entrant problems with blind pushing... This is why at some point I created ubuntu_latest_cmake_install / ubuntu_latest_autotools_install and tstCMakeInstall.sh / tstAutotoolsInstall.sh...

[mmuetzel]

I agree that a good CI coverage is useful. I can try to look into that.

Would it be ok to split the (currently huge) workflow file into multiple ones (one per platform) first?
That would make it easier to temporarily disable tests for some platforms on my fork while trying to implement that. (I'll likely need a couple iterations until that is setup correctly. And it would save some CI cycles if it would trigger only the tests on Ubuntu.)
GitHub supports disabling (entire) workflows temporarily. But it doesn't give a good option to temporarily disable on a job-in-a-workflow level.

[fghoussen]

For now, my advise would be:

1. at your side (on your fork), first remove all CI jobs.
2. then add 2 CI jobs that will run fast
3. when OK, revert step 3 (on your fork)
4. push force the branch after removing 1 and 3

This is the way I did that when I had to... So you can do what you need without opening a PR (split CI) inside another unrelated one (custom mpi)!

I can try to look into that.

Thanks! :)

split the (currently huge) workflow file into multiple ones first?

Yes but in another PR!... Mixing both would be a mess... I let you decide which way you wanna go

[mmuetzel]

Yes but in another PR!... Mixing both would be a mess... I let you decide which way you wanna go

I opened #489 with a proposed change for that.

I'll mark this PR as draft until that one has settled.

[fghoussen]

@mmuetzel: On this PR, could you update the link in the README

It seems broken as the yaml of the CI changed.

[mmuetzel]

Sorry for the late reply. I'm currently being caught up in other projects.
I'll try to come back to this PR as soon as time permits.

In the meantime, I opened #493 to address your last comment. (Thank you for pointing that out.)