On Sat, 27 Jul 2002, Paul D. Smith wrote: > %% 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.
I was hoping I could avoid having to use either of those; Imake especially. "include" is something that I've gotten to like quite a bit, and Frotz now depends on this. > >> 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. I'll withdraw that. You answered my question at the bottom of this post. > 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. I agree. I think I'll send a pr to NetBSD about that. > 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. I see. So except for my include, I suppose my Makefile is now POSIX compliant. -- David Griffith [EMAIL PROTECTED] _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
