Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!mjm!mjf From: mjf@mjm.mjm.com (Mark Fresolone) Newsgroups: comp.sources.wanted Subject: Re: anyone want to redesign make? Message-ID: <260002@mjm.mjm.com> Date: 22 Apr 91 15:01:59 GMT References: Organization: Melillo Consulting, Somerset, NJ Lines: 35 | pds@lemming.webo.dg.com (Paul D. Smith) / 7:26 pm Apr 18, 1991 / | * make was not designed to work in large environments, i.e. ones | where the source is spread out in many different directories. In | particular, I'd like to be able to do something like: | 1) Have a "stable" directory with valid, stable source in it. | 2) Have a working directory in which exist only the files I'm | modifying. | 3) When I build, have make build a local copy of the target if I | have a local copy of the dependancy. If not, then make should | use the stable version of the target if it exists. If it | doesn't, make should build a local copy of the target from the | stable dependancy. AT&T uses "nmake", an implementation with usability problems of its own, but one which uses a PATH-style variable called VPATH for "view path" to point to a list of dependency directories of the nature you describe. You can leverage off off of existing binaries, as well as source from other "more-stable" tops-of-trees, although there is (or was when I last saw it) no checking for matching compiler options. Some folks in AT&T said it would be re-marketing nmake as of last year. The most advanced, distributed, cycle-conserving build manager (actually Configuration Manager) is probably DSEE from Apollo. It's Binary Pools automatically maintain not only versions of source, but compiler options and version of the build tools (/bin/cc, etc.). Of course, it is still proprietary...... Make was state of the art fifteen years ago. *make are sophisticated hacks. It is interresting to see new technology which provides no real upward compatibility, yet adheres somehow to acient, outdated, but venerated paradigms. of course, in some cases, it's just "code reuse gone amuk". Mark Fresolone mjf@mjm.com, rutgers!mjm!mjf Melillo Consulting/MJM Software 908-873-0620/Fax 908-873-2250