- View this page in:
I love SlackBuilds, the scripts to compile programs and create packages for Slackware. I was amazed after reading a great article explaining the advantages of using SlackBuilds VS. manually compiling with "./configure && make && make install". Unfortunately, the page is gone (it was the site of a Slackware based Brazilian distro called GoblinX, which then became ImagineOS but sadly stopped being updated).
The other day, I got a message from a person trying to use my scripts for installing Orca on Slackware (which I updated to work with 14.1, by the way!), with doubts about SlackBuilds in general. So I decided to explain, and this was the answer I gave him:
Basically, a SlackBuild is just a Shell script that sets some common variables (like which architecture your machine is), applies some patches if needed, and specifies which options to pass to "./configure" (like telling we'd like the binaries installed in "/usr/bin" and the libraries in "/usr/lib", instead of "/usr/local/bin" and "/usr/local/lib" which are usually the defaults if you don't specify it in "./configure"). It copies the documentation files to the appropriate places, compiles the program, then packages everything into a ".tgz" or ".txz" (if you use, for example, "tar -tf packagename.tgz" to view its contents, you'll notice that it's like the directory structure of your filesystem, with "usr/bin" etc., compressed with Tar and Gzip). These packages are very easy to install with "installpkg". When a package is installed, a file with the name of the package minus the ".t?z" extension is put in "/var/log/packages" listing all files that were installed with that program. And (one of the things I like the most), they're also very easy to uninstall with "removepkg". If the program was compiled with just "./configure && make && make install" manually without the SlackBuild (therefore not packaged and not tracked in "/var/log/packages"), it's much harder to know which files were installed where, and for removing them, the easiest way is to go to the directory with the program's source (having to download the source code again if we don't have it anymore, do "./configure" with the same options we used to install it the first time - if we remember what was passed, that is :P - to generate the makefile again), then use "make uninstall" (and guess what? Not every program with "make install" also has the "make uninstall" option! So, can you imagine the problem?)... Whereas if we had installed it through a Slackware package, we could remove it just by doing "removepkg packagename", and Slackware's package tools would take care of finding and removing the files correctly. In other words, it's wonderful :D.
This occurred to me later, so I didn't send it in the answer. Some people like to use programs like Checkinstall, which monitors "make install"'s output to find out where the files ended up, then creates an installable package (it supports many distros, including Slackware), but personally I prefer using SlackBuilds (even though it myght be a bit more work to create a script if I can't find one for the program I want) because it serves as an organized way to document the options and steps to compile the program, very useful when needing to upgrade and compile it again.