[petsc-dev] Reverse dependencies

[Barry Smith]

On Sep 13, 2012, at 7:55 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> On Thu, Sep 13, 2012 at 8:50 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> On Sep 12, 2012, at 9:49 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 
> > This patch seems to do two very unrelated things. More importantly, it makes libpetscmat depend on libpetscksp, thus breaking single-library=0. The register routine needs to be moved to src/ksp to fix this.
> 
>     Yup. My mistake.
> 
>      I don't like the idea of shoving it directly in KSPRegisterAll(). Instead what about KSPMatRegisterAll() that is called, like KSPRegisterAll() by KSPInitializePackage()
> 
>      Similarly you would have SNESKSPRegisterAll() for your KSPPOLY.
> 
> Fine, so SNESInitializePackage() would call SNESKSPRegisterAll() and the user should call one or the other if they don't use SNES but want to use those KSP implementations.
> 
> Bear in mind that it'll work automatically with dynamic libraries since the package is initialized when the shared lib is loaded. Now should we also use the constructor trick to let the user skip this on all systems supporting the attribute (most).

     I don't really care, it is fine with me if you want to do this.

   Barry

>  
> 
>     Barry
> 
>    Note also the manual page for MatRegisterAll() should have a reference to KSPMatRegisterAll().
> 
> 
> >
> > In principle, I'd be fine with putting it in KSPRegisterAll. Instead of thinking of that routine as "register all implementations of KSP" (which it never truly meant), I think of it as "register all implementations of anything provided by the KSP package". The downside of that is that MatCreate calls MatInitializePackage, but does not call KSPInitializePackage, causing MatSetType(S,MATSCHURCOMPLEMENT) to fail when !defined(PETSC_USE_DYNAMIC_LIBRARIES) and KSPInitializePackage() has not been called.
> >
> > Unfortunately, I there isn't a way short of static constructors to initialize only those packages that are linked. With C++, we could have a static constructor that registered itself. With GCC and related compilers, we can use __attribute__((constructor)) to get a routine called before main (it would add the existing XXInitializePackage() to a list that PetscInitialize() would call later). Both of these options run code before main which means we have to be especially careful that it never causes an error because that is very confusing.
> >
> > On systems that don't support constructors, I think the user will have to call KSPInitializePackage themselves if they are going to MatSetType MATSCHURCOMPLEMENT before KSPCreate. I think this particular combination is extremely unlikely, but I have a similar issue with my new KSPPOLY (the implementation needs SNES to solve a constrained minimization problem) and that makes sense to use via -ksp_type poly when the user does not interact with SNES at all.
> >
> > changeset:   ec8eb69c0c42
> > user:        Barry Smith <bsmith at mcs.anl.gov>
> > date:        Thu Aug 23 08:03:00 2012 -0500
> > files:       conf/test include/petscksp.h src/ksp/ksp/utils/schurm.c src/mat/interface/matregis.c
> > description:
> > added testexamples_opengl rule
> > changed MatCreateSchurComplement to use the MatCreate_SchurComplement() paradigm
> >
> 
>