[petsc-dev] PETSc-3.4 PR open at https://github.com/Homebrew/homebrew-science/pull/343

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>   It seems you are willing to drop the /petsc/ portion of some things (like finclude) if all the files are name spaced inside but I like total consistency. Why not 
>
>   prefix/include/petsc  subdirectory of finclude and private (won't need the petsc- part anymore)?

I think I was in favor of this a while back when we moved the private
headers, but this is fine and people would write

#include <petsc/snes.h>

and (some) plugin-writers would use

#include <petsc/private/kspimpl.h>

>   prefix/lib/petsc          subdirectory of modules?

The shared library itself should go at prefix/lib/libpetsc.so so that
the normal -L and RPATH flags behave as expected.  Non-library stuff
that somehow relates to execution would make sense to put in
prefix/lib/petsc.  For example, externally-distributed plugins could go
in prefix/lib/petsc/plugins/*.so where they would be loaded
automatically.

>   
>   prefix/share/petsc subdirectories of data and conf?

That's fine.

>   prefix/bin/petsc

No, because this breaks PATH.  If prefix is a "normal" location, the
normal environment variables should do their job.  Asking someone to
export PATH=$PATH:$prefix/bin/petsc is not reasonable.

>     then we can organize everything inside the PETSc subdirectories
>     the way we like.  But, of course, #include <petscvec.h> won't work
>     even if prefix is /usr without a -I 

We would not ask for a special -I$prefix/include/petsc.
-I$prefix/include should be enough, just like every other library.

>    and -lpetsc won't work without a -L But we don't generally talk
>    about using PETSc that way anyways (since for portable makefiles
>    for different installs of PETSc on different systems one shouldn't
>    assume -lpetsc works).  

I think it is selfish to ask for special directory flags.  Shared
libraries are popular outside of HPC systems and they're easy to use
when people follow conventions.  We should support the preferred binary
interfaces on distributions that express a preference.  I.e., we should
make life easier for packagers.  Yes, projects with portable build
systems need to obtain the build flags from us because of things like
transitive dependencies when using static libraries.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131012/0aef6520/attachment.sig>