runcutest with meson

[dpo]

The runcutest script doesn't work with the meson install. This issue is to remember to adapt it.

[nimgould]

Yup, that is because the script requires links to external software, often beyond our control. This is trivial for static libraries, as you know, but from what I understand from you mesonites, less so for shared ones.

[amontoison]

@nimgould We compile static libraries by default with Meson for CUTEst.

[dpo]

It’s just that runcutest looks for files that are only around in the Makefile-based install.

[amontoison]

Is it enough to specify the installation subfolder like in the "makemaster" build system?
-> https://github.com/ralna/GALAHAD/blob/master/README.meson#L12-L15

[dpo]

In Homebrew, setting CUTEST to the install folder doesn't work. Setting it to the source folder won't work either since it will be deleted. I think runcutest needs to be adapted.

[dpo]

From #99 (comment)

While I am sympathetic to an update to runcutest, we must not break the old faithful one as this is the one that has generated 3000 CUTE/r/st citations, and is still used by many people we know

Absolutely. Perhaps a second script is in order, one for use with the Meson build system.

[jfowkes]

Perhaps we need a runcutest_standalone routine much like we have for sifdecoder?

[nimgould]

The issue here is that CUTEst has (at least) two purposes: 1) provide the tools so that others can use problems described by SIF, and 2) provide interfaces to external packages. runcutest is design for the latter, but leaves it up to the user to define how the external package is linked. We provide a very general, and deliberately flexible, framework for the linking. I am not sure how having a standalone package would deal with this. I am not against this, only I feel it is up to you chaps to provide it as it would inevitably be huge time sink - we have interfaces to around 50 external packages, including Matlab, and we haven't as yet decided how to do Matlab with GALAHAD using meson.