Rich Cook wrote:
> Hmmm... How is placing a useful library in a standard location like
> /usr/local/lib "pollution?"
When you install into /usr/local, and Apple installs into /usr/local, you
can never be sure where a particular library comes from. And if everyone
installs into /usr/local, what if two packages want two different versions
of a library? You start running into "DLL Hell", to use a Windows term.
And also because Apple can blow away anything in /usr/local at any time they
like with one of their system updates.
> It has to be put somewhere, and although it does make it easier to
> automate their maintenance if they are segregated into Frameworks, having
> this great Apple scheme to put libraries in unusual paths with unusual
> compiler flags to access them is a bother to people who just want to port
> to OS X codes that already run on Unix.
Yes and no. There are codes that I know of for Linux, SGI, etc. that carry
around their own copy of things like Inventor, JPEG, HDF, VTK, etc. so that
they always know they can rely on their dependencies being around. This is
the "UNIX" solution to Frameworks.
> The only way for Apple to win this battle is to make it easy to do it the
> "right" way and the "wrong" way at the same time.
I agree. And I think that's the situation we're in. You are able to the
"carry around your own library" method both in the "standard" way and the
Framework way. You can install DarwinPorts, fink, both, or neither. You
can install into /usr/local, or wherever you like. I think the situation
we're in is nice, from a developer's point of view, because you can do
pretty much anything you like. The downside is that there isn't "one way to
do it", which means you can't rely on how someone else might do it.
-Sean
__
email@hidden
925-422-1648
_______________________________________________
scitech mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/scitech
Do not post admin requests to the list. They will be ignored.
