%% Dave <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
