sveer@sssab.se (Sven L Eriksson) (02/21/91)
The X11 makefiles (produced by Imakefile) uses a feature that isn't documented in my system (Sys V.3.2) although it works. They use a double : instead of a single in the dependency rules. This allows several rules with the same name. The effect is that all these rules are executed. If a makefile contains: foo :: @echo making foo bar :: @echo making bar foo :: @echo making more foo then "make foo" will produce making foo making more foo If single : are used instead make will complain. Is this a general undocumented feature of make? X11 is portable to a lot of platforms so I guess they have thought about this. But do make on all systems have it? Dare I use it in makefiles that are going to be ported to many different systems. Thanks for any responses. / Sven -- - Sven L Eriksson, 3S AB (Scandinavian System Support AB) o O___ _________ - Address: Agatan 4, Box 535, S-581 05 Linkoping, Sweden _][__|o| |O O O O| - Phone: +46-13-11 16 60 Fax: +46-13-11 51 93 <_______|-|_______| - Email: sveer@sssab.se UUCP: uunet!sunic!sssab!sveer /O-O-O o o
d87-mal@hemul.nada.kth.se (Mats L|fkvist) (02/25/91)
I could find it even in an old set of V7 manuals, not in the man-page but in
the separate article about make (on newer systems as Pyramid OS and Sun OS it
is also mentioned in the man-page). Does the V.3.2 documentation include ANY of
the articles from "Volume 2" of the Unix manuals (lex, yacc, vi, {nt}roff etc)?
If not, the are probably available at extra cost :-)
_
Mats Lofkvist, d87-mal@nada.kth.sear@mcdd1 (Alastair Rae) (02/26/91)
The :: has another (undocumented) effect. Try this --
all: x y
x:
touch x
y::
touch y
First time through you get touch x and touch y, as you'd expect.
Second time through you only get touch y; the :: is a sort of
do-it-always rule.
Perhaps someone with access to makefile source could tell us what
:: is _supposed_ to mean.
--
Alastair Rae : uunet!ukc!mcdd1!ar : +44 442 272071 : *Usual disclaimer* guy@auspex.auspex.com (Guy Harris) (03/12/91)
>The :: has another (undocumented) effect. Try this -- > > all: x y > > x: > touch x > y:: > touch y > >First time through you get touch x and touch y, as you'd expect. >Second time through you only get touch y; the :: is a sort of >do-it-always rule. > >Perhaps someone with access to makefile source could tell us what >:: is _supposed_ to mean. Well, if by "makefile source" you mean "make source", they can just tell you want it means in that particular version of "make"; that may not be what it means in some other version, nor is it necessarily what it was *supposed* to mean - there may be a bug in that version, or it may not have been intended to mean anything. The System V Release 3.x (dunno what "x" is; we may have moved in the S5R3.1 or S5R3.2 updates) "make" documentation (not the manual page, the stuff in the Programmer's Guide), says (yes, the double-colon stuff *is* documented there): A dependency line may have either a single or double colon. A target name may appear on more than one dependency line, but all of those lines must be of the same (single or double colon) type. For the more common single-colon case, a command sequence may be associated with at most one dependency line. If the target is out of date with any of the dependents on any of the lines and a command sequence is specified (even a null one following a semicolon or tab), it is executed; otherwise, a default rule may be invoked. In the double-colon case, a command sequence may be associated with more than one dependency line. If the target is out of date with any of the files on a particular line, the associated commands are executed. A built-in rule may also be executed. As I read it, it says nothing about double-colon being a "do this always" mechanism - it doesn't talk about what happens if there aren't any dependencies on the dependency line. The V7-vintage "make" in 4.3BSD, the S5R2-derived "make" in "/usr/old/make" in SunOS 4.0.3, and the Sun-developed "make" in "/usr/bin/make" in SunOS 4.0.3, all show the behavior you describe; whether this is intentional or just an unintended consequence of the implementation, I don't know. (The Sun one may be "intentional" to the extent that the implementation mirrors the AT&T ones, or that the behavior was intended to mirror the AT&T one.)