🚀 go-pugleaf

In two places, the Makefile for make-3.57 uses abolute
path names for source files. This is a lose, because
it prevents you from keeping the sources and binaries
in different directories. [That is, without editing the
Makefile. If it were not for this glitch, one could
just have a stub Makefile in the binary directory.
The stub includes the distributed Makefile from the
source directory, and sets VPATH and CFLAGS approriately.]

The point is that the Makefile should both work stand-alone
(when used by either standard make, or gnu make), as well
as when it is included in a more complicated make setup.
One solution is to replace the explicit {load,remote}.c
by $*.c (or some other automatic variable).
Another solution depends on a normally-undefined macro
- this is $(srcprefix) in the diff shown below.

*** Makefile.orig	Thu Oct 19 16:29:54 1989
--- Makefile	Wed Nov 22 20:36:57 1989
***************
*** 107,113
  	mv -f make.new make
  
  load.o: load.c
! 	$(CC) $(CFLAGS) $(LOAD_AVG) -c load.c
  remote.o: remote.c
  	$(CC) $(CFLAGS) $(REMOTE) -c remote.c
  

--- 107,113 -----
  	mv -f make.new make
  
  load.o: load.c
! 	$(CC) $(CFLAGS) $(LOAD_AVG) -c $(srcprefix)load.c
  remote.o: remote.c
  	$(CC) $(CFLAGS) $(REMOTE) -c $(srcprefix)remote.c
  
***************
*** 109,115
  load.o: load.c
  	$(CC) $(CFLAGS) $(LOAD_AVG) -c load.c
  remote.o: remote.c
! 	$(CC) $(CFLAGS) $(REMOTE) -c remote.c
  
  TAGS: $(srcs)
  	etags -tw $(srcs)

--- 109,115 -----
  load.o: load.c
  	$(CC) $(CFLAGS) $(LOAD_AVG) -c $(srcprefix)load.c
  remote.o: remote.c
! 	$(CC) $(CFLAGS) $(REMOTE) -c $(srcprefix)remote.c
  
  TAGS: $(srcs)
  	etags -tw $(srcs)