As this article shows, it's possible to use make to create executables or libraries that mix language modules within a single project. Do you think this capability is useful? What types of projects have you (or would you) use it with? Do you think Microsoft should add this capability to Visual Studio?
Manage Cross-Platform Projects with the make Utility
Make is a powerful program maintenance utility that has been deployed by our colleagues in the UNIX world to automate the build process for decades. Learn how to use the concepts behind this versatile tool in the .NET world to integrate CLR compliant languages and more.
by Hasmet Akgun
November 5, 2002
ong before Windows became the de facto operating system on the desktop—even before IBM released the first Personal Computer with 16KB of memory, software engineers had realized the need for automation tools to facilitate large-scale development efforts. In 1960s and 70s, when software projects began growing in complexity, developers found it increasingly difficult to work in unity with each other. Unforeseen problems during integration often forced the team back to coding. Furthermore, in some extreme cases, two programmers' combined efforts could be producing less reliable code when compared to any one of them working alone. It started to become clear that two programmers were not necessarily twice as productive as one. These observations contradicted the conventional wisdom of the industrial age. The software industry definitely needed new methods to make development efforts more predictable. Most of the tools and concepts we take for granted today flourished out of this crisis: source code control systems, structured programming, and even object oriented programming, to name just a few.
The Basics of make
One of the important products of the period is the make utility, which consists of a simple, yet expandable rule evaluation engine geared towards producing binary executables from source files and libraries along with a makefile consisting of the rules. The difference between make implementations in UNIX and Windows is considerable, but the underlying concepts are the same:
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
ong before Windows became the de facto operating system on the desktop—even before IBM released the first Personal Computer with 16KB of memory, software engineers had realized the need for automation tools to facilitate large-scale development efforts. In 1960s and 70s, when software projects began growing in complexity, developers found it increasingly difficult to work in unity with each other. Unforeseen problems during integration often forced the team back to coding. Furthermore, in some extreme cases, two programmers' combined efforts could be producing less reliable code when compared to any one of them working alone. It started to become clear that two programmers were not necessarily twice as productive as one. These observations contradicted the conventional wisdom of the industrial age. The software industry definitely needed new methods to make development efforts more predictable. Most of the tools and concepts we take for granted today flourished out of this crisis: source code control systems, structured programming, and even object oriented programming, to name just a few.
