[petsc-dev] Sean is going to love this

[Geoff Oxberry]

On Sun, Jan 4, 2015 at 6:34 PM, Sean Farley <sean.michael.farley at gmail.com>
wrote:

>
> Jed Brown writes:
>
> > Sean Farley <sean.michael.farley at gmail.com> writes:
> >> The only problem with using non-system compilers is with C++ because
> >> clang++ is not ABI compatible with g++. You could use gcc just fine if
> >> there was something to enforce the induced dependency graph.
> >
> > Uh, isn't this libc++ vs libstdc++ rather than clang++ vs g++?  Note
> > that merely mixing -std=c++11 code with a single compiler can be a
> > problem.  C++ repeatedly chooses language features that make binary
> > compatibility difficult.
>
> Yes, a slip on my part. I meant libc++ vs libstdc++ not being ABI
> compatible.
>
> >> Nope, nope, nope, nope. Using multiple package managers, including
> >> the broken python ones is a suggestion that is dead on arrival. I sure
> >> as shit don't want to remember the different commands to search for a
> >> package with multiple managers (Python, Ruby, node, etc.). Plus, it
> >> doesn't solve the issue with packages that depend on other packages not
> >> in its system.
> >
> > I agree with Sean that mixing package managers is a mess.  Maybe if I
> > lived in a self-contained Python-only world, but I don't.  I want to be
> > able to reliably install (and upgrade, remove, query) a package that
> > depends on any subset of packages.  That could mean mixing Python,
> > Haskell, R, and Emacs packages.
>
> Exactly.
>

I also agree that mixing package managers is a mess. I still prefer it to
manual installation in most cases. A single package manager solution would
be best, but I have yet to see one effectively incorporate existing
language-specific package ecosystems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20150104/61915c58/attachment.html>