Skip to content

Build it from source

More and more, I’m noticing a depressing trend. I know I’m about to cringe or face palm whenever I read or hear, “I’m just used to building everything from source.” This is a super scary concept to me, because it gives me hints about what is coming up next.

In the computing world, there are quite a few solved problems. Maybe all these problems aren’t solved as eloquently as you might or expect, but generally what you are doing right now has probably been done before.

One of these problems that has been solved a countless number of times in package management. Almost all major Linux distributions use a package manager of some sort, and they all pretty much get all the easy points right. Even my Mac which I use for most of my productive work these days has a choice of a few different package management options.

While researching Rails 3 today, I came across a particular blog post. While scrolling through the comments, I came across this gem,

“I’m simply used to doing the source way”

Now, this is an innocent enough sounding statement on the surface. Of course it is pretty simple to untar and and ungzip source distribution. It is even pretty easy to run configure, make, and make install. What happens after is the painfully depressing part; how exactly do you know what version of what you have installed?

I’m actually not sure why this bothers me. Maybe it is the fact that is pretty damn simple to create packages using Portage, RPM, Deb, and believe it or not, it pretty damn simple to create packages on your Mac.

So the next time you install something by hand, take the few extra minutes to package it up to save yourself some future pain…. or

./configure --prefix /tmp && make && make install

Posted in yerdoinitwrong.

Tagged with .

View Comments

By bryanl – January 18, 2010

  • I'm a bit confused by this post. My post is about installing Ruby 1.9 and setting it up in a way that does not take over the local Ruby version except you request it in the current terminal session. The other way pointed out was using RVM. RVM is just a script that does what I did in fewer commands(excluding the RVM install commands). So it's just different commands to do exactly the same task.

    I would rather say that the reverse is dangerous. A *Developer* that is unable to do simple tasks as *building software* is simply not a developer worth a damn. Sometimes you need to build from source. Like in this case where the package management tools won't do the trick.

    For day to day operations I tend to use Homebrew. Exception to that are tools like Erlang where I am usually a few releases ahead of package management tools. Less of a problem in Homebrew but I used to do that a lot when I used MacPorts.

    PS. Relying on the package manager to reliably tell you the version is ill advised. You should ask the software what version it is.
  • "PS. Relying on the package manager to reliably tell you the version is ill advised. You should ask the software what version it is."

    So with 100 pieces of software, I'm sure there are at least 50 ways to ask it what its version is. My point is that you don't need all that confusion. It actually is easy to add anything you are compiling to some sort of package management if you are on Linux or the Mac. For that reason alone, I figure it is better to do it than to not do it.
  • So you should ask the package manager what version of the app is? Then when you actually use the library it might then be a different version that what the package manager thinks there is. A package manager does not know the system and it does not know what version the system or software in question will find and use. It only knows the version IT installed. I'm sorry but what you are talking about is what creates confusion.

    So I should recommend that everyone just use a package manager in my post? Thus overwriting the version of the software they have used for development and breaking all the rails application they are developing?

    Package manager are for setting things up in a correct and organized way. If your are writing and flooding the package management repos with some edge case testing installations then you are doing more harm than help to the community.

    Plus. I must reiterate that people need to know this. They need to know manual installation of software even though they use package management software. Exactly like programmers need to know about HTTP and the innards of the web even though they use frameworks like rails.

    PS.
    Btw.. Don't take my comments here as some angry rants against someone who didn't agree with my post. It's all said with simley faces. I just don't completely agree with you. :)
  • justinwr
    If you can't find the version number of a library or piece of software, that software isn't doing anyone a favor. Even most alpha software I've used have version numbers on commands and libraries alike. So the problem lies in uninstallation or upgrading.

    1. Uninstallation is a bitch when you don't know what has been placed into your system. Generally though, if the software is of any higher quality they'll use typical conventions found on most UNIX systems. /usr/local/* will have easily identifiable pieces.

    2. Upgrading I never seem to have a problem with. The only issue is when you upgrade something that hasn't been overwritten or symlinked to a newer version. Other then that, I've never had issues.

    Also, what's more dangerous is the masses of people I'm finding that have absolutely no experience compiling in general, due to severe package management usage. Generating your own packages is one thing, but blind faith in a package management solution is another.

    I can't count how many times my Slackware experience has come into play fixing or installing beta software for R&D.

    In conclusion, Macports for the stuff you understand how it works, but play with the source and compile it yourself for things you want to learn more indepth.
  • On ubuntu you do:

    ./configure && make && checkinstall

    http://manpages.ubuntu.com/manpages/jaunty/man8...

    Checkinstall will install a package from source and add it (with version info) to the package manager.

    Like you said, most of these problems are already solved :-)
blog comments powered by Disqus
« »