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

[Aron Ahmadia]

Sorry, the homebrew folks are doing a decent job of working correctly
in the open source OS X space.  There are a million package managers
doing a reasonably good job in the GNU/Linux world.

A

On Sat, Oct 12, 2013 at 8:00 PM, Aron Ahmadia <aron at ahmadia.net> wrote:
>>   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