configure does not find PETSc from Fedora's repositories

[gtheler]

If $PETSC_DIR is empty, configure sets it as /usr/lib/petsc which works for finding PETSc installed from the repositories in both Debian and Ubuntu. This procedure fails on Fedora.

[gtheler]

The thing is that, unlike Debian and Ubuntu, Fedora separated the C header includes from the make includes and did not respect the structured of PETSc's source tree. This leads to checking for a valid PETSC_DIR far harder for configure.ac. @vitorvas can you take a stab at it if you have some time?

[vitorvas]

Yeah, sure. As you said, I think I must come up with some weird exceptions on configure.ac to make the also weird PETSc Fedora package detectable.

[vitorvas]

The command

PKG_CHECK_MODULES([PETSCVAR], [petsc], [AC_MSG_RESULT([${PETSCVAR_CFLAGS}, ${PETSCVAR_LIBS}])], [AC_MSG_ERROR([PETSc library not found])])

on configure.ac gives me the following output (cut):

checking pkg-config is at least version 0.9.0... yes
checking for PETSCVAR... yes
-I/usr/include/petsc , -L/usr/lib -lpetsc

Still need to find out how to trim the -I and -L -lpetsc from the output variables, but I think this is an option.
However, still weird: I get /usr/lib/petsc but PETSC is at /usr/lib64/petsc... Not a big deal as ldconfig knows how to find it. But I just don't like to get the wrong directory.

Do you know anything about pkg-config? Because as more as I dig, more confused it gets (at least in Fedora).

[gtheler]

Here's the thing I found when playing with Fedora a couple of weeks ago: the petsc pagackage does not maintain the structure of the source tree so the procedure to find a manually-compiled PETSc tree (the one that configure.ac has) fails. Luckily, in Debian and Ubuntu, when installing petsc-dev it is like having manually uncompressed and compiled the source tree in /usr/lib/petsc so the procedure to find an automatically-installed PETSc is the same as the one for the manual case with PETSC_DIR=/usr/lib/petsc and PETSC_ARCH="".

Now, since detecting a manually-compiled PETSc is a must, I am reluctant to change the current approach. I was thinking of something like "if I didn't find anything manually and the procedure for /usr/lib/petsc did not work then make another attempt and see if a Fedora-only procedure can find something."

The main thing to do is to locate the variables file so it can be included in FeenoX' makefle:

# if slepc is found we need to include its makefile,
# otherwise petsc and otherwise nothing
rm -f src/variables.mak
AS_IF([test "x${have_slepc}" = "xyes"],
  [echo "include \$(SLEPC_DIR)/lib/slepc/conf/slepc_variables" > src/variables.mak],
  AS_IF([test "x${have_petsc}" = "xyes"],
    [echo "include \$(PETSC_DIR)/lib/petsc/conf/variables" > src/variables.mak],
    [touch src/variables.mak]
  )
)

So to answer your question: no, I don't know anything about pkg-config. If you make it work for Fedora, we can add it below the current approach which works for manual and Debian-based installed PETSc but fails in Fedora. In that case, your addition will fire and everyone would be happy, wouldn't they?

[vitorvas]

Now, since detecting a manually-compiled PETSc is a must, I am reluctant to change the current approach. I was thinking of something like "if I didn't find anything manually and the procedure for /usr/lib/petsc did not work then make another attempt and see if a Fedora-only procedure can find something."

We're on the same page here: we must add a work-around for Fedora and not touch the code that works for Debian and Ubuntu. They're the ones who are installing PETSc the way PETSc developers expect.

The main thing to do is to locate the variables file so it can be included in FeenoX' makefle:

# if slepc is found we need to include its makefile,
# otherwise petsc and otherwise nothing
rm -f src/variables.mak
AS_IF([test "x${have_slepc}" = "xyes"],
  [echo "include \$(SLEPC_DIR)/lib/slepc/conf/slepc_variables" > src/variables.mak],
  AS_IF([test "x${have_petsc}" = "xyes"],
    [echo "include \$(PETSC_DIR)/lib/petsc/conf/variables" > src/variables.mak],
    [touch src/variables.mak]
  )
)

If at least Fedora had the variables file installed with PETSc pakage...

So to answer your question: no, I don't know anything about pkg-config. If you make it work for Fedora, we can add it below the current approach which works for manual and Debian-based installed PETSc but fails in Fedora. In that case, your addition will fire and everyone would be happy, wouldn't they?

Again I'm with you. I'm just wondering if the it is worth the work. After all, Fedora doesn't even bother to provide SLEPc as a package. So much work to detecting PETSc as a package in Fedora just to make the user realize it must install SLEPc from its tar.gz because he/she has no other option... It seems too much trouble to the avail of the small set of feenox users that run Fedora and just want to use PETSc without SLEPc functionality.

[gtheler]

If at least Fedora had the variables file installed with PETSc pakage...

I installed Fedora 33 in Vagrant and I see this:

[vagrant@fedora33 ~]$ ls /usr/lib64/petsc/conf/
petscrules  petscvariables  rules  variables
[vagrant@fedora33 ~]$

Again I'm with you. I'm just wondering if the it is worth the work. After all, Fedora doesn't even bother to provide SLEPc as a package. So much work to detecting PETSc as a package in Fedora just to make the user realize it must install SLEPc from its tar.gz because he/she has no other option... It seems too much trouble to the avail of the small set of feenox users that run Fedora and just want to use PETSc without SLEPc functionality.

Indeed. But what are you going to do when time comes for you to prepare the Fedora package for FeenoX? :-D

[vitorvas]

I installed Fedora 33 in Vagrant and I see this:

[vagrant@fedora33 ~]$ ls /usr/lib64/petsc/conf/
petscrules  petscvariables  rules  variables
[vagrant@fedora33 ~]$

And you're right. The same happens for Fedora 34. My mistake here.

Indeed. But what are you going to do when time comes for you to prepare the Fedora package for FeenoX? :-D

Man, you have a pretty good point. I can't dodge this. :-)
I'll keep you updated on my progress.