| A. G. Hume, Mk: a successor to make , USENIX Phoenix 1987 Summer Conference Proceedings, 445-457 (1987). |
....compiler interface changes. make can enhance the development cycle by providing the thread to close these tool based seams. To do this with minimal user overhead, however, requires some basic changes to the make command. Such changes have been going on for years, but in a somewhat haphazard way [CF, EP, Hume, Palk, SM, SV1]. The following interrelated goals give direction to these changes. make must: easily scale from one to many users . do accurate change propagation . have sensible information distribution . run with reasonable speed . provide portable configuration management These goals are discussed in ....
....develop the shipped product, the target makefile language can even be a monolithic shell script that simply does a one time product build and installation. 8. Experience The ideas and features proposed here have been incorporated to a limited extent in the publicly available make implementations [Fowl, Hume, Palk, SM], and to a greater extent in commands based on different models [Clem, Wate] The Bell Laboratories nmake command (internal version) provided the basis for the arguments in this paper, and so supports them all. Although nmake is not backwards compatible with make, it is used in hundreds of ....
A. G. Hume, Mk: a successor to make , USENIX Phoenix 1987 Summer Conference Proceedings, 445-457 (1987).
....b.o. If the b.o action executes before y.tab.o then the compilation will fail because y.tab.h will not have been generated yet (or worse, the compilation will succeed by using an old and possibly incompatible y. tab.h) A fundamental feature of nmake [Fowl85] Fowl90] GNU make [SM89] and mk [Hume87] is that prerequisite lists are not ordered. In contrast to other makes, nmake also provides automatic #include prerequisite analysis that prevents errors of omission as in the previous makefile example. Because of this all nmake makefiles are by default parallelizable. Handling the details of ....
Andrew G. Hume, Mk: a successor to make, Proc. of Summer 1987 USENIX Conf., Phoenix, 1987.
....a virtual processor. pmake doesn t wait for the virtual processor to finish, but continues processing the list of dependencies in which the target appeared. The parallelism is hidden from the description file writer. It doesn t burden the programmer with all the details of the parallelism. Mk [7], which is an enhanced version of the original make, supports program construction in a heterogeneous environment. To exploit the power of multiprocessors, it executes maintenance actions in parallel. The number of jobs run in parallel is user settable by defining the macro NPROC. Mk interacts ....
A. Hume. Mk: A successor to make. Technical Report 141, AT&T Bell Laboratories, Murray Hill, NJ, Nov. 1987.
....are silently accepted by Version 7 compatible makes. The compatibility results from the use of make s syntax to specify parallel constructs and options. Make interprets, for example, a .MUTEX rule as a rule to be applied when creating a target .MUTEX, instead of a special command. 7.3. Mk Mk [21], like nmake, is an enhanced version of the original make. The number of jobs run in parallel is user settable by defining the macro NPROC. The number of concurrent jobs is 1 by default, which implies serial execution of the commands. Unlike nmake, cmake and pmake, mk has no provision for the ....
A. Hume, "Mk: A Successor to Make," Computing Science Technical Report No. 141, AT&T Bell Laboratories, Murray Hill, NJ, November 1987.
.... Make, UNIX wouldn tbewhat it is today.However, inthe last years a number of attempts have been made to improve the program in a number of ways, complete reimplementations have been done, and quite a lot of criticism has (respectfully,though) been expressed, of what is considered weaknesses of Make [2, 3, 7, 8, 10, 14, 16]. Often, the discontent is related to some kind of specialized new task that Make is put to work on, which it wasn toriginally designed to perform. So, this kind of criticism can also be interpreted as some compliment for a very flexible tool. In [16] it is argued that one of Make smore serious ....
Andrew Hume, "Mk: A Successor to Make," Proceedings of the USENIX Summer Conference,USENIX asc., Phoenix, Ariz., June 1987.
....for the odin cache manager process is TCP IP. If TCP IP is not available, set the environment variable ODIN LOCALIPC and Unix domain sockets will be used instead. 1. 3 Why Not Just Use Make The most ubiquitous build manager is Stu Feldman s Make program[3] with its many descendents[2] 6][5][4] Although ideal for small projects, Make has two major problems when used for large or complex projects: inaccurate dependency information and poor support for variant builds (such as builds for different architectures or builds with different levels of compiler optimization) Inaccurate ....
A. G. Hume. MK: a successor to make. In USENIX Summer Conference Proceedings, pages 445--457, 1987.
No context found.
A. Hume, "Mk: A Successor to Make," Computing Science Technical Report No. 141, AT&T Bell Laboratories, Murray Hill, NJ, November 1987.
No context found.
Hum87. A. Hume, "Mk: A Successor to Make", USENIX Association Conference Proceedings, Phoenix, Arizona, pp. 445-458 (Summer 1987).
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC