Firstly, breaking vendor space (here, the
/usr/bin directory) is rather a bad idea, as other vendor packages may depend on
make 4.1 being available, or vendor updates to
make may conflict or break on account of the manual changes made to the vendor space, or perhaps undo your changes. A better option is to install your version of
make elsewhere, for example to
/usr/local/bin—though on *BSD systems that area is used by packages, so check your vendor's documentation on where things should go, then pick somewhere else when making a software depot of your own, e.g.
/opt or whatever made-up name is suitable to your environment. Granted, this does mean that you are responsible for updates (in particular, security updates) to the software under that software depot, a drawback that can vary from negligible to horrific, depending on the software and site.
As to the compile step, it would run (with a custom software depot path of
/usr/local) along the lines of:
tar xjf make-3.81.tar.bz2
./configure --prefix=/usr/local && make && make install
Any application that then needs the olden version of
make would need to set the
PATH environment variable to list
/usr/local/bin before the
/usr/bin (or now on some Linux, also
env PATH=/usr/local/bin:$PATH yoursoftwarethatneedsmake3.81 ...
Or manually in the shell rc or webserver or whatnot configuration. This could be problematical should an application need the old version of
make, but does need something else from
/usr/bin that is masked by other software under
/usr/local/bin; to avoid this,
make could be installed to a versioned directory:
./configure --prefix=/opt/`uname -m`/make-3.81
And then applications would need (assuming amd64 on Linux)
/opt/x86_64/make-3.81/bin listed first in their
PATH. Or, if you only run one architecture you could simplify the path to just
/opt/make-3.81, or go more complicated with
/opt/centos7/x86_64/make-3.81 to support multiple operating systems under a single tree. As additional software is installed in such a fashion, something like Stow may help managing such versioned installs without making
PATH tediously long. With sufficient care, attention, and resources, a software depot built something along these lines may evolve into something like Apollo, though the ideal software depot form (if any!) for a particular site will vary depending on the size of the site, how much out-of-vendor-control software needs to be installed, etc.