On Wed, Jun 26, 2019 at 11:55 AM Jed Brown via petsc-dev < petsc-dev@mcs.anl.gov> wrote:
> "Smith, Barry F. via petsc-dev" <petsc-dev@mcs.anl.gov> writes: > > >> On Jun 26, 2019, at 9:56 AM, Balay, Satish via petsc-dev < > petsc-dev@mcs.anl.gov> wrote: > >> > >> On Wed, 26 Jun 2019, Jakub Kruzik via petsc-dev wrote: > >> > >>> Hello, > >>> > >>> as I mentioned in PR #1819, I would like to use SLEPc in PETSc. > >>> > >>> Currently when PETSc is configured with --download-slepc, it defines > >>> PETSC_HAVE_SLEPC and each compilation of PETSc recompiles SLEPc. > >> > >> yes - slepc uses petsc, so when petsc is updated - its best to rebuild > slepc > >> > >> You can ignore PETSC_HAVE_SLEPC flag [its just a build tool thingy] > >> PETSc code does not use this flag - and there is no circular > >> dependency. > >> > >>> The first way to use SLEPc is from an example. That should be easy, > all we > >>> need is to add -lslepc when compiling an example. > >> > >> Its best to use slepc examples as templates - and slepc makefiles [as > examples]. > >> > >> --download-slepc is a convinence feature to install petsc and slepc in > >> a single go. It does not change how you would use slepc. > >> > >> Satish > >> > >> > >>> > >>> The other option is to use SLEPc inside PETSc code. I do not know how > to > >>> achieve this. One way could be to define PETSC_HAVE_SLEPC after the > >>> compilation of SLEPc and again compile PETSc but this time linking > with SLEPc. > >>> Although, even if it works, it is ugly. > > > > If you make SLEPc calls from PETSc source you should only need the > SLEPc header files to compile the PETSc source; not the SLEPc library. So > one way to accomplish this would be to do a "partial" install of SLEPc, > build PETSc (that uses SLEPc) and then complete the SLEPc install. When > --download-slepc is used this would mean during the SLEPc.py script it > would copy over the SLEPc include files to the prefix location and after > PETSc is built it would build the SLEPc libraries and move them to the > prefix location. The on iffy thing is that SLEPc include files may depend > on generated PETSc include files (which are not fully generated until > configure is done). Thus instead of having SLEPc.py move the SLEPc include > to the prefix location it would need to post-pone that until just at the > end of configure (we have other packages to do this). So when you ready to > try this out let us know and we can help with the infrastructure. (it will > avoid 2 builds of either PETSc or SLEPc). > > That is disgusting. > > If code in libpetsc.so depends on libslepc.so, then you'd have a circular > dependency. > > > You can implement and register a PC in SLEPc (it would go in libslepc.so). > I think this is the bad workflow solution. What Barry suggested will work and be MUCH easier for a developer. Isn't the point of our tools to make our lives easier, not to enforce rules that make them harder? Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>