Re: $< won't work

[Paul D. Smith]

%% Dave <address@hidden> writes:

  d> An ongoing goal of my work with Frotz
  d> (http://www.cs.csubak.edu/~dgriffi/proj/frotz/) is to make is as
  d> widely and easily portable as possible.  This is why I want to be
  d> able to support *BSD make and GNU make.

If you truly want to make it as widely and easily portable as possible,
you should not be targeting _either_ *BSD make or GNU make: you should
be targeting the POSIX standard definition of make.

Unfortunately, that leaves you without a _LOT_ of useful functionality
supported by most, but not all, makes.  For example, the POSIX standard
does not provide for any type of "include" feature in makefiles.

That's why tools like Imake and automake were invented, after all.

  >> In short, the Xmame makefile is expecting make to perform implicit rule
  >> searches _even if you give it an actual command script_, which is
  >> bizarre and not portable.

  d> I see.  So in what I eventually copied from someone else's Makefile makes
  d> explicit these rules?

I didn't quite understand the question.  If you meant, what about your
rule makes it explicit, then any rule which contains both a specific
target file (not a generic pattern) _and_ a command script is by
definition explicit.  "Explicit" means that make does not have to try to
figure out what rule to use to build the target from its built in (or
augmented) list if "implicit" rules: you explicitly provided a rule and
that's the rule it will always use.

  d> Sidenote: How about implementing local variables like .ALLSRC,
  d> .TARGET, and so on?  (see *BSD make(1) manpage).

  >> I don't have a copy of this manpage.  Is it available on the web?

  d> See http://man.netbsd.org for manpages for manpages for NetBSD 1.3.3,
  d> 1.4.4, 1.5.3, 1.6A, and Redhat 7.0.

Eh.  These "short variable" names which are there "for backward
compatibility" and are "not recommended" are the POSIX standard names
and they've been around for 20+ years.  I'm not interested in following
BSD in trying to obsolete them; there's no good reason to do so.

If you find them more readable, you can easily support them in the same
way as I suggested supporting $>:

  >> > = ^

Sorry, actually this should be:

  > = $^

  >> to your makefile, or in some "portability" makefile you include with the
  >> MAKEFILES environment variable or something.

Add to the same place:

  .TARGET = $@
  .ALLSRC = $^

etc.

  d> I've found a solution that satisfies both NetBSD's make and GNU make;
  d> adding the following to the end of the Makefile:

  d> .SUFFIXES:
  d> .SUFFIXES: .c .o .h

  d> .c.o:
  d>         $(CC) $(FLAGS) $(CFLAGS) -o $@ -c $<

Right; here you are declaring an implicit rule (in this case a suffix
rule) which says, "for any target ending in .o you want to update, if
you have a file ending in .c you can build it with this rule".

Contrast that with this:

  foo.o:
            $(CC) ...

which says, "for the explicit file foo.o (only), if you want to update it
you can run this command to do so", and makes no mention of a .c file.

  d> I borrowed the above from Nitfol's Makefile.  I'm not sure if I
  d> should bother trying to satisfy FreeBSD's make at this point right
  d> now.

The above it 100% portable make, so you should not need to worry about
FreeBSD's make.  Any tool which doesn't understand this is not make.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist