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

[Aron Ahmadia]

>   This whole prefix/include and prefix/lib seems rather silly and archaic; who uses it but the gnu/linux people ?  For example on MacOS the PETSc install location is /Library/Frameworks/PETSc.framework,  on Windows they must have some convention but it sure as hell doesn't use include and lib.
>

Barry, your code runs on Supercomputers.  Last time I checked, there 3
Windows machines on the Top 500, and no OS X machines.  Even leaving
that model, the homebrew folks, who seem to be the only ones operating
correctly in the open source space, use a prefix installer.  Your
general audience is scientific software developers.  They equally
develop in Windows, OS X, and Linux.  But computational scientists
overwhelmingly use Linux-ish environments.

>    Why does the linux world (which is tiny) cling to this archaic model?
>

Because the only way to build massive systems of interoperating
components is to establish archaic APIs and pray that you don't have
to break them.  This has gone poorly for every Linux distribution that
has tried.  See Jed's earlier comments about the Linux Standard Base:
http://www.linuxfoundation.org/collaborate/workgroups/lsb

>    Since the #include <petsc/petscvec.h> can handle the includes, it all comes down to the single -llibpetsc issue of working without requiring a -L flag. We could put the library in prefix/lib/petsc and then make a link back up to the prefix/lib directory.
>

I see why this might be more aesthetic, but it's not the way things
are done, so you shouldn't do it.

>    We could also put put everything in prefix/petsc and then scatter the needed links in for the standard locations.
>

No.  This is the package manager's job.

>    Has anyone in the gnu/linux world came out with viable replacements for the /include  /lib  mess they have now that allows all the parts of a library package to go together rather than being spewed in several directories?

This is why package managers exist.  If you play by the standard
prefix rules, they can deal with the joys of managing multiple
versions of your software.  If your software breaks these rules, you
don't motivate anybody to help get your software portably installed.

A