The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman)
@ 2023-08-03  0:01 segaloco via TUHS
  2023-08-03  0:55 ` Larry McVoy
  0 siblings, 1 reply; 2+ messages in thread
From: segaloco via TUHS @ 2023-08-03  0:01 UTC (permalink / raw)
  To: tuhs

> And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary.
>
> Warner Losh

You're right, I just tried it out.  Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway.

Also shows how little I've used specifics of BSD, I've never made a Makefile using bsd.prog.mk, although I have this desire for a write-once-build-everywhere Makefile that the preponderance of build systems that generate them imply is an exercise in futility...

On that note, one quirk I've found with the implicit .c.o rule on older UNIX, just tested on V7 and System III, is that they render:

cc -c $<

rather than

cc -c -o $@ $<

If you have an object list with objects in several different directories, it spits them all out in the CWD, causing problems if you have similarly named files in multiple directories, and then outright failing on the final compilation if it's something like $(CC) -o $(BIN) $(OBJS) because $(OBJS) is a string of object pathnames with the full nested path, not just the resulting *.o files.

Granted, I could be anti-patterning here for all I know, I haven't worked closely with a whole lot of Make-based projects that aren't my own.  Maybe I just haven't read these darn papers I'm always hunting down enough.

- Matt G.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [TUHS] Re: Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman)
  2023-08-03  0:01 [TUHS] Re: Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman) segaloco via TUHS
@ 2023-08-03  0:55 ` Larry McVoy
  0 siblings, 0 replies; 2+ messages in thread
From: Larry McVoy @ 2023-08-03  0:55 UTC (permalink / raw)
  To: segaloco; +Cc: tuhs

On Thu, Aug 03, 2023 at 12:01:16AM +0000, segaloco via TUHS wrote:
> > And I think even V7 make supported what you described, as well as implicit rules for compiling .c into a .o or into a binary.
> >
> > Warner Losh
> 
> You're right, I just tried it out.  Been avoiding that pattern for years because I swear some make implementation I used at one point was very unhappy with that, but if V7 does it, then whatever implementation that was is probably not what I want to be using anyway.

For years, I carried around some early version of make source.  Maybe Sys
III make?  It wasn't fancy but it behaved how I understood it should
behave and all the other makes, ESPECIALLY gnu make, were adding features
like crazy and, while cool, they were not portable.

I really like stuff that Just Works (tm) and really early make felt like
that.

I'm a dinosaur, there was a saying at my company "Oh, that was invented
after 1980, Larry won't let you use that" which was mostly correct but
I let you use stuff like mmap().  Also not that portable but oh so useful
when it worked.

--lm

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-08-03  0:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-03  0:01 [TUHS] Re: Make(1) Historical Behavior (was Cool talk on Unix and Sendmail history, by Eric Allman) segaloco via TUHS
2023-08-03  0:55 ` Larry McVoy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).