dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jul 05, 2005 at 02:22:41PM -0500, Matthew Knepley wrote:
> Anders Logg <logg@xxxxxxxxx> writes:
> 
> > On Tue, Jul 05, 2005 at 02:08:19PM -0500, Matthew Knepley wrote:
> >> 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.
> >
> > Couldn't you just add an extra flag or two? Should be possible since
> > there is a finite set of ways to compile PETSc.
> 
>   I guess this is where we have aesthetic differences. You see no problem with
> introducing something new into the model you like (petsc-config), but everything wrong with
> the equally simple model we like (make). We are the same in this. I think if the
> package maintainer wants to include petsc-config, that is fine with me.

There's nothing wrong with your model. It's just that I and everyone
else is used to a different model and thus it requires extra work to
learn the PETSc model.

> >>        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.
> >
> > But all I need to compile against PETSc is a single text string and I get
> > the same string every time I do 'make getincludedirs'.
> 
>   No, you get a different string depending on the value of
>   PETSC_ARCH.

Yes, but PETSC_ARCH is known at compile-time (of PETSc) and then the
script could be generated. And PETSC_ARCH stays constant over time, at
least on my machine... :-)

> >>       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?
> >
> > It matters since if it were called petsc-config I wouldn't have had to
> > ask you how to do it.
> 
>   make <option>   <-->    petsc-config <option>
> 
> and you would will need all the bmake directories.

Yes, but the bmake directories would not be needed after PETSc has
been installed and the script been generated. Or am I missing something?

/Anders

>        Matt
> 
> > /Anders
> >
> >>     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/