I would like to better understand installing from source using the make command

./configure
make
make install

My question is: How to make make install in a folder I choose?
Instead of installing the program on my Linux, I would like to install it in a folder, to always run it from that folder.

shows options.

where to install
that requires more knowledge on PATH and such, especially if you're not going to install it in /usr or /usr/local. Reading INSTALL and README , configure --help should help you as well.
Knowing
in case you mess something up too is worth putting in your toolbox. That requires not getting rid of the source at least until you know for sure it works the way you/it is intended to.

2 members found this post helpful.

This is a caveat to be aware. If the option is not supported then removing all files might be a chore.

Usually considered an improvement is using a build script that is actually a wrapper to the make commands. Once a package is created files are more easily removed by the distro package manager without any concern about whether make uninstall is supported.

@Nick-us

AFAIK you need to use the configure directive BW-userx presented:
- it will define the program destination tree and where the program will look for its dependent files when it will be executed

And to avoid what upnort mentioned, I suggest to always build a package:
https://docs.slackware.com/howtos:sl...ding_a_package
- get used with building packages under Slackware, it's really easy. After you get some more experience you'll end up with the "The "I don't have time" way"

1 members found this post helpful.

If interested in a build script template, one is available at slackbuilds.org.

1 members found this post helpful.

There's two parts.

The "--prefix" flag to ./configure

and

The "DESTDIR" argument to make.

The average SlackBuild (Slackware package-building) script uses both.

1 members found this post helpful.

@dugan

With the observation that DESTDIR is only used for a temporary/staged installation which is not the location from where the program will be executed.
https://www.gnu.org/prep/standards/h...e/DESTDIR.html

1 members found this post helpful.

If and when the OP gets more familiarized with the Makefile in the notation for uninstall and the program the OP is installing, that can too be modified to ensure that it uninstalls everything, by adding it in, (fun? For some perhaps).

Things like windowmaker and e16 can be installed in places other than /usr and /usr/local. ie. ones home dir. Perhaps OP might want to take a look at them to see how they do it to get them to work. There are the libs, and other areas of interest to the program as well that one might want to take into consideration when installing a program other than what is considered the 'norm' in location fo rit to be installed in.

Slackbuilds are a good thing to learn how to use and manipulate to curtail them to the users needs between the user and the system.

one way round this ( ugly )
as an unprivileged user
everything will fail be you see where it tries to put things
if it is a BiG list, redirect stderr to file

if the src is not already compiled, it will compile it first ( not ideal ).


( less ugly )
Really the Makefile is just a shell script, so it wouldn't take much to "reverse engineer" the install target(function)

With this in mind, one could archive the Makefile, remove the Src ( if disk space is a premium )
using the Makefile
A Script could be produced to

• check files still exist
• check UID/GID Mode are still the same
• check sha/md5 sums ( would have to grab them after install )
• execute an uninstall ( or move to temp location for later deletion )

might not be worth doing
alternative config/make systems seem to be gaining popularity


still, if make uninstall doesn't work, make -k install is worth remembering

If you're going to do a bunch of scripting/bookkeeping to make sure all the files are tracked, it would be better to just create a Slackware package instead.

1 members found this post helpful.

If I were were going to do a bunch of scripting/bookkeeping to make sure all the files are tracked.

I would do it.

It is actually not that bad these days. With modern `find` you can easily locate all files associated with a package, if you know just one file provided by the package. The following is a shell script that will automate finding files that are likely to be related to your reference file, based on common install time. Just run it as root providing a single argument, that being the path to the chosen reference file.

The result will be all files that were "changed" (installed from this perspective) 10 ten seconds before and 10 seconds after the reference file, in common install locations, which would almost certainly be everything related to the install and only that. This is a reasonable range as the file install step for most packages is usually less than a couple of seconds on modern hardware, for even large packages. 10 seconds is also short enough it that is unlikely anything else changed within that time (at least for software you are compiling and installing back to back). However with a second argument you can also tweak the time window (just supply a number representing how many seconds before and after).

P.S. More detail of how this works and related tricks can be found here.

7 members found this post helpful.

Just to add to all of the excellent information above, anything you compile using
should install itself under /usr/local by default. This location contains only a few empty directories on a standard slackware installation, and is provided specifically for the purpose of accepting locally compiled software without breaking the package management system.

If you want to know more about the options you have when compiling & installing anything from source, you can use:
This will give you a list and brief explanation of all of the switches available to you for that particular piece of software.

Once the software is compiled (i.e. after 'make', but before 'make install'), you can use the DESTDIR variable to install it wherever you like, regardless of the options chosen at the 'configure' stage:

3 members found this post helpful.

This is what I've been doing for more than 2 decades on Slackware, /usr/local is my "parallel world" where I put my own compilations. Never managed to break something, nor failed to clean something.

...slackin' since 1996...

2 members found this post helpful.

Indeed and you can normally just delete the entire contents of “/usr/local” (and subdirectories) if you feel that things have gotten too messy or out of hand. Then just issue the following as root (this assumes `bash` as your shell) to recreate the entire “/usr/local” sub-directory structure as it exists in Slackware 14.2.

I got the above from looking at the contents of the “aaa_base-14.2-x86_64-2” and “perl-5.22.2-*-1” packages (or `bzgrep usr/local MANIFEST.bz2` also works).

Alternatively, you could refer to “/usr/local : Local hierarchy” section from FHS 3.0 to see what sub-directories are considered standard or expected. Using that as a guide, you could probably get away with this as a bare minimum:

Most reasonable software you would install should create any further directories that they actually needed.

1 members found this post helpful.