Re: superfluous GNUism in the makefile

>>>>> Taylor R Campbell <[email protected]> writes:

 >> The rule for the SRFI 27 library in Scheme48's makefile refers to
 >> the GNU-specific `$^' variable.  Since there is only one source file
 >> to which it refers by that variable, you can just substitute `$<',
 >> which is in POSIX.

 > Sorry, this is wrong: $< is not defined (except by accident) outside
 > of a prefix rule.  But anyway, you can just substitute the name of
 > the source file, c/srfi-27.o, and avoid any of these problems.  The
 > same goes for the other rules that use $<, except for the .c.o prefix
 > rule, which can still use it.

	Do you mean, e. g., the following one?

   188	CC_POSIX = $(CC) -c $(CPPFLAGS) $(DEFS) -I ./c -I$(srcdir)/c -I$(srcdir)/c/bibop $(CFLAGS) $(DYNAMIC_EXTERNALS_CFLAGS) -o $@ $<
   189	
   190	$(posix_dir)/user.o: c/posix/user.c \
   191		$(SCHEME48HS) c/c-mods.h $(posix_dir)/posix.h
   192		$(CC_POSIX)

	Alas, the use of $< here is for a purpose.  Namely, in the rule
	above, $(srcdir) may or may not be prepended to the dependencies
	($(srcdir)/c/posix/user.c, etc.), thanks to the VPATH magic:

     6	### Filled in by `configure' ###
     7	srcdir = @srcdir@
     8	VPATH = @srcdir@

	Thus, albeit mere VPATH specification doesn't make the Makefile
	GNU-specific, for this VPATH magic to work in GNU Make it's
	essential to use $< even for no-pattern rules.

	It's fine to remove $< from the c/srfi-27.o rule, but doing so
	didn't add portability to the Makefile.in as a whole, while
	trying to achieve such portability will ruin the --srcdir=
	support.  Which is, in my opinion, to high price to pay.

	Anyway, are there any Scheme48 users with Makes for which this
	Makefile is going to fail?

-- 
FSF associate member #7257