[DOLFIN-dev] [knepley at mcs.anl.gov: Re: [PETSC #13286] Make pcimpl.h a public API]

[Anders Logg]

On Tue, Jul 05, 2005 at 01:20:34PM -0400, Faheem Mitha wrote:

> On Tue, 5 Jul 2005, Johan Jansson wrote:
> 
> >Hi,
> >
> >Below is some discussion about PETSc standard installation and
> >packages. It seems that a petsc-dev package should include the PETSc
> >source, and thus that DOLFIN can assume the PETSc source is available
> >when building. This would solve both the pcimpl.h issue as well as the
> >issue of extracting PETSc compiler flags.
> 
> Hi,
> 
> I mean no disrespect, but I think that assuming that the source is 
> available would make life much more difficult for packagers, is very 
> non-standard, and generally undesirable. If you don't believe me, ask 
> people on an appropriate technical mailing list. 
> debian-devel at lists.debian.org comes to mind.
> 
> In general a *-dev should contain headers files and that is all. I could 
> probably find some technical standards material to quote you on this if 
> you wanted.

Yes, I'm familiar with this standard as a long-time Debian user.
Of course we should try to follow the standard whenever possible.

> If I understand correctly, you want to access some internals of PETSc, so 
> having the 'public' headers available is not sufficient since you want to 
> compile against a header that defines a 'private' implementation, is that 
> correct?

Yes.

> I don't know what the best way of resolving this is, but I do think that 
> compiling DOLFIN should work 'out-of-the-box' on a 'make install' of 
> PETSc.

I agree.

The problem as I see it is that PETSc does not follow the
standard. Even if you do a 'make install' in PETSc, you still need to
define a PETSC_DIR, right? And then there's the problem of getting the
compiler flags and libs. A petsc-config script installed by PETSc
'make install' in $prefix/bin/ would be useful.

As I've said, I'd be happy to update DOLFIN to work with an installed
version of PETSc. I don't know the details so I can't do it right now,
but I can figure it out and do it later or someone can send me a patch.

In particular, the next stable release of DOLFIN (will be out today)
will require a user to download PETSc 2.3.0 and do

    export PETSC_DIR=`pwd`
    ./config/configure.py --with-clanguage=cxx
    make all

> I can see three possibilities.
> 
> a) The PETSc 'make install' adds these internal details as necessary
> to a make install.  This would be a reasonable solution. One could
> argue that if someone needs to access these private details, then
> perhaps they should be regarded as public.

I think this is the best alternative.

It might also be the case that we should really not access pcimpl.h
and there are ways around this. I have not looked at this in detail so
I don't know.

> b) The packager adds these files to the PETSc package to make the
> compilation of DOLFIN work. I'm certainly willing to do that if you
> told me what and where to put the extra files.
> 
> However, this means DOLFIN would not compile with the result of a
> PETSc 'make install'. Also, this solution does not scale well, since
> some other package may want to access some other internal
> stuff. However, this would still be better than expecting the full
> source to be present.
> 
> c) DOLFIN includes those files itself. This is another possibility
> which is not ideal, since DOLFIN should not really be shipping bits of
> another package.

This is the second best alternative.

> However, still preferable to assuming the source is available.
> 
> Please bear in mind that the current size of PETSc, as I have packaged
> it, is around 130 Mb. This is already on the large size for a library
> package, and having to make the source available would make this even
> larger. I'd like to figure out ways to make this smaller.

That seems unreasonably large. The Debian package is 1.4MB (4.2MB
installed). Maybe you can talk to Adam Powell? (I see that you have
submitted a request to package 2.3.0 already.)

> Please, I beg both the DOLFIN and PETSc development teams to reconsider. 
> Again, I mean no disrespect. I appreciate all your hard work and 
> expertise, and just want what is technically best.

So do I, thanks for your comments!

/Anders