I'm trying to figure out the best way to install from source. Do I need to keep around the "make" directories if i want to upgrade or uninstall it some day? I've been doing this from the home directory and then just deleting those make directories one I have the app installed.

Best way on slack

First read what options are avialable and include the ones you want.
$ ./configure --help | less

$ ./configure --prefix=/whatever
$ make

Next make a temp directory for the packages.
$ mkdir /slack

Next install the package into that directory
$ make install DESTDIR=/slack

Then make a slack packages of it.
$ cd /slack
$ makepkg whatever.tgz

$ installlpkg whatever.tgz

Next you can delete all the source and files in /slack and put the whatever.tgz wherever you like. Now you can go into /var/log/packages and see you package and remove it in the future if you want.

Some addings to chbin's thread:

think about first moving your package and then deleting everything _else_ in /slack ;-)
A word about package naming: It's recommended to name the packages in the same syntax as Pat (and other package builders, see linuxpackages.net) do - I'll explain this shortly with an example:

I rebuilt xmms today due to a bug I've found (downloaded a patch and patched it). The new package is named

xmms-1.2.10-i686-2sep.tgz .

This follows the syntax <program_name>-<version_number>-<architecture>-<build_number><yourshort>.tgz.
Read that syntax again, please.
"xmms" is the program's name, it's version is "1.2.10", the architecture I've built it for (my machine :-) is Intel's 686 processor architecture (Pentium II and above), the build number is 2 (since I've built it before to optimize it for my PC, and that one was build number 1), and my self-chosen short is "sep". So, as things are put together, you receive the package name which is standing above.

This way of naming packages lets you easily remember what a package contains; for example, if you put thunderbird in your own package, and it's broken half a year later, there might probably me two or three "thunderbird.tgz" packages hanging around on your hd. How can you determine safely which one was installed?
I hope you got the point and wish you lots of fun with building packages :-)

Greetings,

Seppel

why not use "checkinstall" after " make ". ( it's upgraded recently ).
it does a good job in building packages.

egag

I compile a lot of stuff from source as I use many programs that do not come with Slackware, and I used to run checkinstall to make a slackpackage each time. The snag I found in my situation was that each time I upgraded Slack (full reinstall from CD of each new release) I had to figure out which programs I had to reinstall as they were all wiped out. I eventually settled on this system:

1 Made a folder called Programs in /home and moved my /usr/local folder into it, leaving a symlink /usr/local pointing to it. (/home/Programs/LOCAL)

2 Each tarball is compiled and installed into /home/Programs/tarball-name

3 In that folder I run a little script I found called ln_local which sets symlinks in/home/Programs/LOCAL pointing to the files in /home/Programs/tarball-name

4 Now the system thinks the program is installed in /usr/local and behaves accordingly, while I know it is all in /home/Programs/tarball-name - and thus can be easily uninstalled by running ln_local again to remove the symlinks then deleting the folder in /home/Programs.

5 Bonus is that I can easily run any number of versions of the same prog simply by installing into a different folder. Usually I call the folder eg inkscape so the links point to /home/Programs/inkscape. When I upgrade inkscape I rename the existing one inkscape-old and install the new one as inkscape - any problems and it is easy to rename and go back to the original. I keep an empty file in each folder named after the version so I know which it is.

6 /home is of course mounted on its own partition so is unaffected when I upgrade. If anything does not then work due to wrong library version etc I run it in the shell to see the error then fix it or upgrade. I also keep old Slackware on its own partition so it can be used with all the /usr/local stuff should I have problems with the new one. The next new one then goes onto that partition, leaving the current one still usable with /usr/local and /home/me.

7 Can anyone see any snags in this system? You do have to study the ./configure --help carefully as some things install configs into /etc, so this has to be changed so everything goes into /home/Programs/tarball-name. I delete all the tarball files once the prog is up and running with no problems.

^That sounds very much like the encap way of doing things. I found encap (and its accompanying epkg package manager) very useful when I was running Linux From Scratch.

If only every Makefile honoured DESTDIR!

If I remember correctly, lack of DESTDIR-honouring is one of the reasons PV came to regard GNOME as a maintenance nightmare. (But I could be remembering incorrectly.)

JohnKFT you do know you can mount things in linux right. why not just put /usr/local on it's own partition and mount it? And that would be that. done! Your method makes something that should be simple complicated.

I compile from source regulerly and I would say 99% of it follows DESTDIR. Every now and then I get something that decides it wants to spam my system so then I just go back and edit the make files. Then complete the package and install. And all the spam is now overwritten by my package of course and everything is clean.

Gnome is just tought to build for anyone. Even with checkinstall or whatever else you want to use. There is just so much to keep track of and the documentation could use some improvement.

That's probably true, but human nature being what it is, I just tend to remember the other 1% with extreme bitterness.

For some "relocatable" packages, I find ./configure --prefix=/slack/usr works OK when DESTDIR is not honoured. But other packages are just broken. For example, when you pass -prefix=/slack/usr (or whatever) to the configure script for Endeavour Mark II, it still puts stuff elsewhere when you come to make install.

I hope you don't actually use the prefix=/slack/usr and it was just an example. Unless you made /slack part of you hierachy and put the libs and bin paths into your envirement otherwise all you libs and executable code would be broken. Even if you did make /slack part of your hierachy it would be highly unusaul.


There is no 100% of being sure everything is OK, especially when building big programs. It is to hard to keep track of and even the developers have a hard time. That is why people have development systems. You find out later that stuff is broken and then you go back and build a package or two again.

I use slackware's patched checkinstall to install thing from source.
If I remember correct, some Slackbuild scripts use the strip command before they pack the program. When is strip needed?

What I meant was that I have occasionally used --prefix=/slack/usr to emulate what DESTDIR does, before doing cd /slack && makepkg /blah-x-i686-1.tgz && installpkg /blah-x-i686-1.tgz. For example, this works perfectly with ffmpeg (whose Makefile doesn't honour DESTDIR).