guard slepc configuration

[tjhei]

I was able to successfully configure with petsc and slepc while slepc was linking to a different petsc installation. I think we should figure out a way to stop this from happening.

[tamiko]

This is not an easy task. :-/

I don't see any obvious way to achieve this and still support all possible installation scenarios.
I'll have a look at whether we can make a best-effort guess with the configuration files we already parse.

[bangerth]

Shouldn't SLEPc store somewhere what PETSc it uses? Or is this never made explicit inside the SLEPc installation?

[oneliefleft]

What you mean by, "what PETSc it uses"? If you mean version, no it is not
stored, but SLEPc only compiles with the same major and minor versions as
PETSc - if they do not match, SLWPc throws an exception at configure time.

Right?

2016-02-28 19:59 GMT+01:00 Wolfgang Bangerth notifications@github.com:

Shouldn't SLEPc store somewhere what PETSc it uses? Or is this never made
explicit inside the SLEPc installation?

—
Reply to this email directly or view it on GitHub
#2167 (comment).

[bangerth]

I expected that in some SLEPc configuration file it records against which PETSc installation it was compiled. That may not be true. But it must have accessed some PETSc installation's header files and libraries during SLEPc compilation and installation.

[oneliefleft]

Yes, I see. As far as I know SLEPc does not record that information. It
accesses the same info (from petscconf.h) as deal.ii does at configure time
and then stores additional information (in slepcconf.h). Sorry to be a pain

• what was the original problem that this thread concerns? What do we want
  to achieve?

2016-02-28 22:03 GMT+01:00 Wolfgang Bangerth notifications@github.com:

I expected that in some SLEPc configuration file it records against which
PETSc installation it was compiled. That may not be true. But it must have
accessed some PETSc installation's header files and libraries during
SLEPc compilation and installation.

—
Reply to this email directly or view it on GitHub
#2167 (comment).

[davydden]

i agree with @tamiko , unfortunately it is not straight forward to do. The problem is that SLEPc, AFAIK, does not record in any config file what PETSc it built against. Until something changes in this behaviour, that issue is a wontfix.

[davydden]

i wrote to the mailing list to ask for this feature and gave a link to this discussion.

[bangerth]

Given that it's not trivial and that the issue is obscure and unlikely to happen to a lot of our users, my vote would be to not sink any more resources into it. What do you think, @tjheister?

[tjhei]

I would assume that we could check if our libpetsc is the same one slepc pulls in. But I agree, we have plenty of other stuff to do.

[davydden]

from Jose Roman on PETSc mailing list

I have added this:
https://bitbucket.org/slepc/slepc/branch/jose/configure

However, I am not totally convinced of this change, because PETSC_DIR is then defined both in petscconf.h and slepcconf.h, so behaviour could change depending on whether user code includes one or the other in the first place.

I will test this further before merging into master.

[bangerth]

Well, that's asking for trouble. They're stepping on the PETSc namespace this way. They should name the variable SLEPC_PETSC_DIR and then let users figure out whether that equals PETSC_DIR.

[bangerth]

Given @tjhei 's comment, let's close this and not try too hard to come up with a solution at this point. If SLEPc at one point in the future has a mechanism to address this, we can always reopen.