PETSc fortran headers not found on a system that has CPATH set

[casparvl]

Describe the bug

I'm building a code that has

petsc = dependency('PETSc', required : true)

in its meson.build. The system I work on (an HPC cluster) has

• PETSc installed in a custom prefix (/<petsc_prefix>/)
• It's CFLAGS include /<petsc_prefix>/include
• It's PKG_CONFIG_PATH includes /<petsc_prefix>/lib/pkgconfig, which contains the petsc.pc file

The meson setup correctly find PETScon this system:

Run-time dependency petsc found: YES 3.20.3

So far so good. However, during the build, I get:

    3 |   use petscksp
      |       1
Fatal Error: Cannot open module file petscksp.mod for reading at (1): No such file or directory

The reason this happens is perfectly clear to me: pkg-config considers anything on the CPATH to be part of the system include files:

$ pkg-config --cflags petsc

$ PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --cflags petsc
-I/<petsc_prefix>/include

That makes perfect sense: if I was compiling C-code, CPATH would already be passed to my compiler, and including this again from the pkg-config side would mean the include path gets added twice. The issue is: I'm not compiling C-style code, but Fortran code, for which the headers happen to be in the same /<petsc_prefix>/include directory.

Looking at this code Meson seems to already know about this issue.

However, to my surprise, I wasn't getting allow_system=True in my case, because self.language is not fortran for this dependency. So, I tried to alter the meson.build to read:

petsc = dependency('PETSc', language : 'fortran', required : true)

however, to my surprise, that was not allowed:

ERROR: PETSc dependency does not accept "language" keyword argument

which is thrown from here. Unless you in this very exclusive list, you are not allowed to specify fortran as language argument, apparently :)

I've been thinking about how best to resolve this, and I think there is only one person who knows that this might be an issue: the developer who writes the meson.build. That person knows their software is including a dependency that (might have) both Fortran and C-style headers in the same place (i.e. for which CPATH might thus be set and for which pkg-config will thus not add that directory include to the compiler arguments). Since this is specific to using the return value of pkg-config --cflags for a fortran dependency, I think it makes total sense for the developer to have to indicate this in his meson.build using

petsc = dependency('PETSc', language : 'fortran', required : true)

What I don't understand is why this language keyword is currently limited to MPI, OpenMP, netCDF and HDF5. Yes, these have more specific behaviour that depends on the language argument (e.g. this), but this is also completely valid language-specific behaviour that would apply to any package that is being used as Fortran dependency and for which the method is pkg-config.

Am I missing something? Is there any reason not to just accept the language argument for any dependency? Or, if you want to be more specific: for any dependency using pkg-config for dependency resolution?

Expected behavior I expect that I have to change

petsc = dependency('PETSc', required : true)

into

petsc = dependency('PETSc', language : 'fortran', required : true)

in my meson.build and that then my software correctly builds against the PETSc dependency.

system parameters

• Is this a cross build or just a plain native build (for the same computer)? cross-compilation (but irrelevant to this context)
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.): RHEL 8.6 (but I use nothing from the OS, my full toolchain & dependencies are build in a custom prefix, as is common in HPC systems)
• what Python version are you using e.g. 3.8.0: 3.11.3
• what meson --version: 1.1.1 (but the relevant code is unchanged in `master)
• what ninja --version if it's a Ninja build: 1.11.1

[mjr-deltares]

Hi, I was wondering if there is any news or follow up expected on this issue?