1. petsc
  2. PETSc
  3. petsc
  4. Issues
Issue #53 new

Compiling plugins seperately from rest of code

created an issue

For each plugin directory, like pc/impls/hypre revise the makefile system so that the source code there can be compiled as is now with the rest of PETSc and into the petsc library but also (by configure option) as a standalone plugin library that can be configured and made AFTER PETSc has been built.

Extreme approach is to rip out the current approach and only make them configure and make separately.

Comments (3)

  1. Jed Brown

    It is the distribution and informing the user of how to link that I'm most concerned with. Separate distribution means we would need another configure.

    • Should that configure trust configure results obtained earlier by PETSc and/or Trilinos build systems? People will accidentally or intentionally change their environments between configures, so trusting earlier results will create support email. But while configure takes one minute on a laptop, it takes an hour on a "leadership" class machine, so re-running configure hurts usability (human time to install).

    • Will there be an option to automatically download? (Most PETSc users use --download-ml instead of installing on their own.)

    • Current users can include PETSc makefiles, run a command-line tool, or use FindPETSc.cmake to determine how to link. If the plugins are distributed separately, where will the user's build system get link information? That step must be exactly the same with or without plugins and with static or shared libraries. Users of shared libraries should be able to link only with -lpetsc.

  2. BarryFSmith reporter

    Here is my thinking (to evolve from what we have now but change as little as possible (in some measure))

    Say PETSc is already installed (with shared libraries) but without hypre support

    From the perspective of the user:

    1) the user downloads the usual PETSc configuration file

    2) the user runs the usual ./configure

    a)  with the additional options —enable-plugins    and somehow indicates the location of the installed PETSc and where the plugins will go
    b) they pass in whatever arguments are needed for an external package, for example —download-hypre or —with-hypre-dir
    c) internally configure uses Matt’s find Petsc thing to make sure the PETSc install is ok, bypasses most of the operations except the external packages and generates appropriate gmake thing

    3) the user runs make ; make install which runs make in the appropriate external library directories, builds the libraries and puts them in the appropriate place.

    If this all works then eventually we could generate a petsc-plugins.tar.gz that excludes all the rest of the code just to be a bit slimmer.

    The point is to reuse almost everything we already have (and just short-circuit unneeded stuff), rather than creating a new infrastructure for building/compiling plugins. Maintain two sets of builders would be nuts and in the end even building plugins will need so much of the infrastructure it would be crazy to write a separate “smaller” infrastructure. (For example some external package .pys need to test for certain blas routines, certain other machine capabilities, we can already do that so just use what we have.

  3. Matthew Knepley

    Its not clear to me that this is useful at all. If one actual user requests this on petsc-maint, I could change my mind.

    1) Configure should be trivial for these plugins, since it will only look for PETSc and the package we are wrapping up. No need for any tests which the plugin does not use.

    2) I do not understand this one. If you can autodownload, you are using PETSc, so just do what we do now. If you are standalone, then you have gotten the source on your own somehow.

    3) I see no reason to have static linking plugins, since if you can statically link, you can do what we do now. Shared library plugins do not need to participate in the build.

  4. Log in to comment