Avery: generally you can ./configure --prefix ~/prefices/make-4.1 && make && make install and you end up with a make installed to that subdirectory which doesn't interact with your system. Put the bin of that tree (in this example PATH=~/prefices/make-4.1/bin:$PATH) on your $PATH and you're good to go. This is a strategy that works for all autotools projects and more besides. It's the basis for homebrew and its ilk.
On Fri, Aug 7, 2015 at 2:22 PM, Avery Payne <[email protected]> wrote: > Thank you. Thank you Thank you Thank you. You just solved a HUGE problem > for me. > > I'm on Debian 7 with my home server, and Debian 7 comes with make < 4.0. > Debian 8 does come with make >= 4.0, BUT, I do NOT want to update to Debian > 8 for reasons I won't go into right now. That means I'm stuck with a make > that won't build s6, unless I download, build, and install a separate make, > which may or may not conflict with the existing install, leading to all > kinds of "good times" that I really don't need. I haven't had time to poke > around Makefiles, so it's not practical for me to address this problem by > editing the existing Makefile. So, in a practical sense, there is no s6 > deployment on my server until I can address this with blood, sweat, tears, > and time. > > Now with your contribution, I have a fighting chance of building s6 by > glomming the Makefile into the build process. That means the possibility > of a s6 build on my existing install, and not worrying about having to do a > complete distribution upgrade to Debian 8. > > > On 8/7/2015 1:50 PM, Buck Evan wrote: > >> Just to make it more concrete, this is what I had to do to eliminate the >> questionable patches from my s6-packaging. >> >> >> https://github.com/bukzor/s6-packaging/commit/0f3465c074446b73fac05defb6118925b92a3c5a >> >> In essence I vendor and build a gnu-make tarball before starting the s6 >> build. >> I'd prefer not to have to do this, but it's not the worst either. >> >> >> >
