dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Barry Smith <petsc-maint@xxxxxxxxxxx> writes:

      Now we are into design issues, but I will chance it anyway. I think packages
without source are silly and pointless. Open source is about having all the source
for everything, especially in the scientific library regime. I therefore agree
with the Gentoo philosophy much more than Debian. PETSc is already packaged the
way I would like it packaged and is designed to work in that mould. I do not believe
the other models work as well, and exist mostly out of inertia rather than consideration
of the benefits and drawbacks.

       Matt

>   These are two related issues, so I have merged them.
>
>   I have always been uncomfortable with the "make install" model
> with PETSc; as you could guess from our incomplete attempt to 
> implement it with PETSc :-(. 
>
> I've aways wanted to have PETSc users
> have the EXACT same experience (debugging, makefiles, rules etc) if they
> used a "compiled" version of an "installed" version of PETSc. I never could
> see how to do this, so I wrote a simple "make install" to pander to those
> who want it :-).
>
> 1)  If "make getincludedirs" and "make getlinklibs" do not work properly for 
> installed versions of PETSc that is a bug we need to fix! I can change the
> install process to also copy over the top level makefile, but this does not
> make sense because having ${INSTALL_DIR}/makefile makes no sense if 
> ${INSTALL_DIR} is something like /usr/local! I could copy it into the bmake
> subdirectory BUT then it is inconsistent with a "non installed" built PETSc.
> Is there a good solution? Maybe most of what is in makefile should really
> be in bmake/makefile?
>
> 2) We could keep the XXXXimpl.h files in a subdirectory of include, instead
> of "where they belong with each component :-)" or have the "make all" and
> "make install" make copies down to a subdirectory of include (I'm inclined to
> do the later) so everyone can link against them in the same place.
>
>    What do you think? Suggestions?
>
>     Barry
>
>   Of course, this does not resolve the neverending problem of not being 
> able to debug installed code :-(
>
>
>
> On Mon, 4 Jul 2005, Johan Jansson wrote:
>
>> Hi!
>> 
>> We've implemented a PetSc preconditioner in DOLFIN, but it seems the
>> preconditioner implementation API (pcimpl.h) isn't a public API
>> (i.e. user code cannot see it). We've solved this by copying pcimpl.h
>> into DOLFIN, but this is not a good solution. Could you consider
>> making the preconditioner implementation API public?
>> 
>> The reason the preconditioner is implemented in DOLFIN and not in
>> PetSc is because the preconditioner depends on DOLFIN. The idea is to
>> solve a nonlinear system in a time-stepping method for ODEs by
>> Newton's method with a Krylov solver preconditioned with a fixed-point
>> solver. The fixed-point solver is part of DOLFIN. There are likely
>> other such applications of externally implemented preconditioners.
>> 
>> Thank you,
>>   Johan
>> 
>> 
>> On Mon, Jul 04, 2005 at 11:44:47PM -0400, Faheem Mitha wrote:
>> >
>> >
>> > On Mon, 4 Jul 2005, Faheem Mitha wrote:
>> >
>> > >On Mon, 4 Jul 2005, Anders Logg wrote:
>> >
>> > >>Look through the PETSc makefile and
>> > >>see if you find the target "getincludedirs".
>> > >>
>> > >>In my petsc-2.2.1/makefile:
>> > >>
>> > >>   include ${PETSC_DIR}/bmake/common/base
>> > >
>> > >Yes, it's there.
>> >
>> > Just to clarify, this is in the sources, but not in the installed library.
>> > You weren't expecting it to be there, were you?
>>
>> Yes, I was. DOLFIN needs to figure out where to find PETSc and it then
>> uses the getincludedirs flag with make to get the correct flags.
>>
>> If possible, I would rather do a 'make install' in PETSc like with any
>> other library (without needing to set PETSC_DIR to something special),
>> but then I don't know how to get compiler flags and link libraries
>> correctly. It would be nice to have a petsc-config script (like
>> gtk-config, xml2-config, dolfin-config, etc) that spits out the flags.
>
>
>

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness