make and archives

[Carl S. Gutekunst]

In article <1160 at ncar.ucar.edu> pack at acdpyr.UCAR.EDU (Dan Packman) writes:
>In OSX4.0, make doesn't properly update library elements...

In article <1951 at questar.QUESTAR.MN.ORG> Scott Anderson writes:
>Nope.  I switched to the ATT make for those particular libraries.  
>
>Have not got this one in to RTOC yet....

And if you do, it will probably be returned from R&D with "user error." :-(
The 4.3BSD make works exactly as it is documented to work. (If this is really
important to you, though, by all means submit it as a bug anyway. You might
be able to change someone's mind. :-))

This is a fundamental philosophical principle of the dual port: you don't go
mixing features from the universes, even when those features are useful. The
ucb make(1) doesn't extract libraries any more than the att vi does handling
of SIGTSTP. Likewise, sockets aren't defined in the att universe, and shared
memory operations aren't defined in the ucb universe. The justification for
this is portability; if you write something that compiles and runs in the
Pyramid's ucb universe, it will also compile and run on a 4.3BSD VAX. If you
compile and run in the att universe, it will run on an SVR3 3B. If Pyramid's
ucb make(1) allowed library extractions, you would now have a variation that
was not portable to other systems. 

Of course, there is nothing from stopping you from using "/.attbin/make". But
then it becomes glaringly obvious that you are doing something non-portable.

I know a lot of people think that a "wall between the universes" is a pile of
dingo's kidneys, and certainly what Sun started in SunOS 3.2 is its very anti-
thesis. But a lot of other people (including me) who have to deal with a lot
of different UNIX systems have found it to be a real life saver. 

<csg>