help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $< won't work


From: Dave
Subject: Re: $< won't work
Date: Sat, 27 Jul 2002 00:02:09 -0700 (PDT)

On Sat, 27 Jul 2002, Paul D. Smith wrote:

> %% 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.

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
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]