On Thu, Jan 20, 2005 at 04:43:49AM -0800, Trent Piepho wrote:
> On Thu, 20 Jan 2005, Michael Hanke wrote:
> > Am Donnerstag 20 Januar 2005 11.09 schrieb Dave Dodge:
> > > Well, yes and no. Installing updated vesions of the autotools is
> > > pretty straightforward if you're used to installing things from source.
> > [snip]
>
> Back when I first installed Linux, we didn't even have these new-fangled
> package managers! Installing from source and building your own kernel was
> the ONLY way. You want binaries? We got your SunOS and OSF/1 and Ultrix
> right here, WTF is Linux? Now days I think rpm, apt, etc. are a god-send to
> keeping a system organized and working.
I've flirted with package managers many times and even contributed
some packages to GoboLinux, but on my home systems I always seem to end
up going back to pure source builds after a while.
> Exactly what I was going to say. Once you install autohell from source,
> you've just broken rpm or whatever package management system you're using.
Yes, I can see this being a problem if you're also using a package
manager. Especially if you do something like install directly from
source into the "managed" directories (that's just asking for
trouble).
Now personally when I do these from-source builds I _never_ install
them into places like /bin and /lib. I keep a strict distinction
between "my stuff" and "the system's stuff". This habit probably
comes from many years of building things for my own use on Solaris
without any admin privileges.
> You'll probably have two versions installed on top of each other using each
> other's files in random and broken ways. And good luck upgrading your
> packages or using something like up2date.
I tend to go to the other extreme: if I'm installing Foo, and it
requires Bar and Baz, then I'll set up a dedicated install prefix for
Foo and put private copies of Bar and Baz in there with it. Example:
in my /opt/gimp-2.0.1 directory I have compiled for use solely by
gimp:
pkgconfig zlib autoconf libtool automake jpeg glib tiff libpng
freetype expat render xrender fontconfig xft atk pango gtk+ libart
libexif gimp-print lcms libmng libxml2 popt librsvg libwmf aalib
libgtkhtml gimp gimp-help
Yes, this means that they all consume tons of disk space, and that
they require extra RAM (because e.g. gimp won't be able to share the
same in-core instance of libgtk as any other applications). On the
other hand, I can copy that /opt/gimp-2.0.1 directory to another
system, or put it on CD, and know that it will pretty much "just
work" without worrying about what versions of those packages are
installed on the target system already.
Note: I have a single Makefile that builds all of that, with awareness
of how the packages depend on each other. So if I decide to swap in a
new version of some single piece I can usually just tweak a few lines
in the Makefile and start a rebuild from scratch.
I'm not saying that I really _like_ doing things this way, but that's
how it usually ends up for some reason. Which is why doing things
like installing a fresh set of autotools, and SDL, and pkgconfig, and
GTK, just to bootstrap mjpegtools probably seems a lot less extreme to
me than it would to most people :-)
-Dave Dodge
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
