dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> writes:

       I think this is a really bad model. First, the examples below assume
a single build, whereas PETSc can have many builds with vastly different
flags. How would petsc-config distinguish these? Whatever the mechanism, it
would still be new since no standard exists.

       Moreover, these options become a single text string with all
semantics stripped out. All this information is in the pickled configure
along with the smenatics in bmake/$PETSC_ARCH/RDict.db. It would be
possible to get all the information from Python that you get from the
make system. No one does it yet, but I like this model. Eventually, our
build will be all Python since make is notoriously limited and not portable.

      However, we have compromised and provided a simple way to get the
flags. Does it matter whether the script is called makefile or petsc-config?
You would still need all the bmake stuff to get the right answer anyway. Right?

    Matt

> A user just needs a simple way to get the cflags and libs. It
> shouldn't be hard to generate this script at compile-time (we do it in
> DOLFIN, see src/config/). Many large projects like GTK use this:
>
> galerkin:~> gtk-config 
> Usage: gtk-config [OPTIONS] [LIBRARIES]
> Options:
>         [--prefix[=DIR]]
>         [--exec-prefix[=DIR]]
>         [--version]
>         [--libs]
>         [--cflags]
> Libraries:
>         gtk
>         gthread
>
> galerkin:~> gtk-config --cflags
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
>
> galerkin:~> gtk-config --libs
> -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
> -ldl -lXi -lXext -lX11 -lm
>
> This script could provide different options for compiling against an
> installed version of PETSc (in $prefix/include, $prefix/lib and then
> PETSC_DIR should not be needed) or to compile against the PETSc
> source tree. DOLFIN has options for this:
>
> galerkin:~> dolfin-config 
> Usage: dolfin-config [options]
>
>        --version  (get version number)
>        --cflags   (get compiler flags)
>        --libs     (get libraries for linking)
>        --compiler (get compiler)
>
>        --cflags_dolfin (for demo programs in the source tree)
>        --libs_dolfin   (for demo programs in the source tree)
>
>> 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?
>
> It doesn't matter to me as long as we can access it.
>
>>     Barry
>> 
>>   Of course, this does not resolve the neverending problem of not being 
>> able to debug installed code :-(
>
> I think the majority of users would rather send an email to the
> maintainers than debugging PETSc themselves, so I don't think it's a
> big issue. Someone who knows how to debug can easily download the
> source and compile against it.
>
> /Anders
>
>> 
>> 
>> 
>> 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.
>> 
>
> -- 
> Anders Logg
> Research Assistant Professor
> Toyota Technological Institute at Chicago
> http://www.tti-c.org/logg/
>
>
>

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