MKWN = MaKe oWN
In software development, make is a utility for automatically building large
applications that would otherwise be time-consuming to build through
non-automated means. Files specifying instructions for make are called
Makefiles. make is an expert system that tracks which files have changed since
the last time the project was built and invokes the compiler on only those
source code files and their dependencies.
make is most commonly used in C/C++ projects, but in principle it can be used
with almost any software project.
make was originally created by Stuart Feldman in 1977 at Bell Labs. Though
Integrated Development Environments and language-specific compiler features can
also be used to manage the build process in modern systems, make remains widely
used, especially in Unix-based platforms.
Origin
There are now a number of dependency-tracking build utilities, but make is one
of the most wide-spread, primarily due to its inclusion in Unix, starting with
the PWB/UNIX 1.0, which featured a variety of tools targeting software
development tasks. It was originally created by Stuart Feldman in 1977 at Bell
Labs. In 2003 Dr. Feldman received the ACM Software System Award for the
invention of this important tool .
Before make's introduction, the Unix build system would most likely consist of
"make" and "install" shell scripts accompanying a program's source. Being able
to combine the commands for the different targets into a single file, and being
able to abstract out dependency tracking and archive handling, was an important
step in the direction of modern build environments.
Modern versions
Make has gone through a number of rewrites, and a number of from-scratch
variants which used the same file format and basic algorithmic principles, and
also provided a number of their own non-standard enhancements, in the time that
followed. Some of them are:
* BSD make, which is derived from Adam de Boor's work on a version of make
capable of building targets in parallel, and survives with varying degrees of
modification in FreeBSD, NetBSD and OpenBSD. Most notably, it has conditionals
and iterative loops which are applied at the parsing stage and may be used to
conditionally and programmatically construct the makefile, including generation
of targets at runtime.
* GNU make, which is part of most GNU/Linux installations and is frequently used
in conjunction with the GNU build system. Its departures from traditional make
are most noticeable in pattern-matching in dependency graphs and build targets,
as well as a number of functions which may be invoked to have the make utility
do things like collect a list of all files in the current directory.
* Microsoft nmake, commonly available on Windows. It is fairly basic in that it
offers only a subset of the features of the two versions of make mentioned
above. Note that there exists another, incompatible program also called nmake
from AT&T and Bell Labs for Unix.
POSIX includes standardization of the basic features and operation of the make
utility, and is implemented with varying degrees of completeness in Unix-based
versions of make. In general, simple makefiles may be used between various
versions of make with reasonable success. Some versions of GNU make and BSD make
will look first for files named "GNUmakefile" and "BSDmakefile" respectively,
which allows one to put makefiles which use implementation-defined behaviour in
separate locations.
Advantages and disadvantages
In its basic form, Make requires the programmer to manually track all
dependencies between files in the project. This process is error prone, since a
forgotten or an extra dependency might not be immediately obvious, but instead
surfaces as subtle bugs in the software. It is possible to create make files
that generate some of these dependencies, but a more common solution is to use
one of the available generators to make, e.g. the Automake toolchain provided by
the GNU Project.
Another problem not well handled by make is the tailoring of a build process to
a given platform. E.g, the compiler used on one platform might not accept the
same options as the one used on another. This problem is typically handled by
generating platform specific build instructions, which in turn are processed by
make. Common tools for this process are Autoconf and Cmake.
The syntax used by Make includes the use of tab, a whitespace character. Many
editors do not provide very clear visual clues to the presence of tabs rather
than spaces, and tab characters are not represented uniformly across editors in
any case, with size varying from as little as 2 spaces to 8 spaces. Thus, the
syntax of make is often subject to criticism. Some projects, such as Apache Ant,
have attempted to redo make with a better syntax, with mixed success. For
programmers using makefile generators, this issue is likely unimportant.
With the advent of modern Integrated Development Environments, especially on
non-Unix platforms, many programmers do not manually manage dependency tracking,
or even the listing of which files are part of a project. Instead, the task is
automated by the integrated environment. Likewise, many modern programming
languages have language-specific ways of listing dependencies which are more
efficiently tracked through the use of language-specific build utilities. These
approaches typically have the drawback that support for arbitrary build
instructions is limited.
Make is considered to be a mainly declarative programming language , and these
languages are sometimes considered more difficult for programmers used to
imperative programming languages
Makefile structure
A makefile consists of lines of text which define a file (or set of files) or a
rule name as depending on a set of files. Output files are marked as depending
on their source files, for example, and source files are marked as depending on
files which they include internally. After each dependency is listed, a series
of lines of tab-indented text may follow which define how to transform the input
into the output, if the former has been modified more recently than the latter.
In the case where such definitions are present, they are referred to as "build
scripts" and are passed to the shell to generate the target file. The basic
structure is:
# Comments use the hash symbol
target: dependencies
command 1
command 2
.
.
.
command n
A makefile also can contain definitions of variables and inclusion of other
makefiles. Variables in makefiles may be overridden in the command line
arguments passed to the make utility. This allows users to specify different
behaviour for the build scripts and how to invoke programs, among other things.
For example, the variable "CC" is frequently used in makefiles to refer to a C
compiler, and the user may wish to provide an alternate compiler to use.
Example makefile
Below is a very simple makefile that would compile a source called
"helloworld.c" using cc, a C compiler. The PHONY tag is a technicality that
tells make that a particular target name does not produce an actual file. The $@
and $< are two of the so-called automatic variables and stand for the target
name and so-called "implicit" source, respectively. There are a number of other
automatic variables.
helloworld: helloworld.o
cc -o $@ $<
helloworld.o: helloworld.c
cc -c -o $@ $<
.PHONY: clean
clean:
rm -f helloworld helloworld.o
CMake is a cross-platform system for build automation. It is comparable to the
Unix Make program in that the build process is ultimately controlled by
configuration files, in the case of CMake called CMakeLists.txt files. Unlike
Make, it does not directly build the final software, but instead generates
standard build files (e.g., makefiles on Unix and projects/workspaces in Windows
Visual C++) which are used in the usual way. This allows developers familiar
with a particular development environment (such as the various IDEs) to use it
in the standard way. It is this use of the native build environment that
distinguishes CMake from most other similar systems like SCons. CMake can
compile source code, create libraries, generate wrappers, and build executables
in arbitrary combinations. CMake supports in-place and out-of-place builds, and
can therefore support multiple builds from a single source tree. CMake also
supports static and dynamic library builds.
The name "CMake" is an abbreviation for "cross platform make". Despite the use
of "make" in the name, CMake is a separate and higher-level application suite
than the make system common to Unix development.
History
CMake was created in response to the need for a suitable cross-platform build
environment for the Insight Segmentation and Registration Toolkit (ITK) funded
by the United States National Library of Medicine as part of the Visible Human
Project. It was influenced by an earlier system called pcmaker created by Ken
Martin and other developers to support the Visualization Toolkit (VTK), an
open-source 3D graphics and visualization system. To create CMake, Bill Hoffman
at Kitware incorporated some key ideas from pcmaker, and added many more of his
own, with the thought to adopt some of the functionality of the GNU build
system. The initial CMake implementation was mid-2000, with accelerated
development occurring in early 2001. Many improvements were due to the
influences of other developers incorporating CMake into their own systems. For
example, the VXL software community adopted CMake as their build environment,
contributing many essential features. Brad King added several features in order
to support CABLE and GCC-XML, a set of automated wrapping tools; and GE
Corporate R&D required support of their testing infrastructure (DART). Other
features were added to support the transition of VTK's build environment to
CMake, and to support ParaView, a parallel visualization system to support the
Advanced Computing Lab at Los Alamos National Laboratory.
Major features
* Configuration files are CMake scripts, which use a programming language
specialized to software builds
* Automatic dependency analysis built-in for C, C++, Fortran and Java,
* Support of SWIG, Qt, via the CMake scripting language,
* Built-in support for many versions of Microsoft Visual Studio including
versions 6, 7, 7.1, 8.0, and 9.0,
* Generates build files for Eclipse CDT,
* Detection of file content changes using traditional timestamps,
* Support for parallel builds,
* Cross-compilation
* Global view of all dependencies, using CMake to output a graphviz diagram,
* Support for cross-platform builds, and known to work on
o Linux and other POSIX systems (including AIX, *BSD systems, HP-UX, IRIX/SGI,
and Solaris),
o Mac OS X,
o Windows 95/98/NT/2000/XP and MinGW/MSYS,
* Integrated with DART_(software), CDart, CTest and CPack, a collection of tools
for software testing and release.
Applications using Cmake
* Bullet Physics Engine
* KDE (starting with version 4)
* The Visualization Toolkit
* Insight Segmentation and Registration Toolkit
* ParaView
* DevIL - Open Image Library
* OpenSceneGraph
* Scribus
* Kicad
* Drishti
* PvPGN
* Chicken
* ParadisEO
* Quantum GIS
* lurc
* MuseScore
* Avidemux
* IGSTK
* Slicer
* Supertux
* H3DAPI
* MySQL (on Windows only)
* Stellarium
GNU Automake is a programming tool that produces portable makefiles for use by
the make program, used in compiling software. It is made by the Free Software
Foundation as one of GNU programs, and is part of the GNU build system. The
makefiles produced follow the GNU Coding Standards.
It is written in the Perl programming language and must be used with GNU
autoconf. Automake contains the following commands:
* aclocal
* automake
aclocal, however, is a general-purpose program that can be useful to autoconf
users. The GNU Compiler Collection, for example, uses aclocal even though its
makefile is hand written.
Like Autoconf, Automake can be quite hard to deal with because it is not
entirely backwards compatible. For example, a project created with automake 1.4
will not necessarily work with automake 1.9.
Approach
Automake aims to allow the programmer to write a makefile in a higher-level
language, rather than having to write the whole makefile manually. In simple
cases, it suffices to give:
* a line that declares the name of the program to build;
* a list of source files;
* a list of command-line options to be passed to the compiler (for example, in
which directories header files will be found);
* a list of command-line options to be passed to the linker (which libraries the
program needs and in what directories they are to be found).
From this information, Automake generates a makefile that allows the user to:
* compile the program;
* clean (i.e., remove the files resulting from the compilation);
* install the program in standard directories;
* uninstall the program from where it was installed;
* create a source distribution archive (commonly called a tarball);
* test that this archive is self-sufficient, and in particular that the program
can be compiled in a directory other than the one where the sources are
deployed.
Dependency generation
Automake also takes care of automatically generating the dependency information,
so that when a source file is modified, the next invocation of the make command
will know which source files need to be recompiled. If the compiler allows it,
Automake tries to make the dependency system dynamic: whenever a source file is
compiled, that file's dependencies are updated by asking the compiler to
regenerate the file's dependency list. In other words, dependency tracking is a
side effect of the compilation process.
This attempts to avoid the problem with some static dependency systems, where
the dependencies are detected only once when the programmer starts working on
the project. In such a case, if a source file gains a new dependency (e.g., if
the programmer adds a new #include directive in a C source file), then a
discrepancy is introduced between the real dependencies and those that are used
by the compilation system. The programmer should then regenerate the
dependencies, but runs the risk of forgetting to do so.
In the general case, automake generates dependencies via the bundled depcomp
script, which will invoke the compiler appropriately or fall back to makedepend.
If the compiler is a sufficiently recent version of gcc, however, automake will
inline the dependency generation code to call gcc directly.
Libtool
Automake can also help with the compilation of libraries by automatically
generating makefiles that will invoke GNU Libtool. The programmer is thus
exempted from having to know how to call Libtool directly, and the project
benefits from the use of a portable library creation tool.
Mk is the build tool replacing make in Version 10 Unix, Plan 9 from Bell Labs,
and Inferno. Improving upon its predecessor by introducing a completely new
syntax that is both easier to read and more powerful. It has been ported back to
Unix as part of Plan 9 from User Space.
License
Mk is licensed under the MIT License and the Lucent Public License, both of
which are free software licences, approved by both Free Software Foundation and
Open Source Initiative.
Apache Ant is a software tool for automating software build processes. It is
similar to make but is implemented using the Java language, requires the Java
platform, and is best suited to building Java projects.
The most immediately noticeable difference between Ant and make is that Ant uses
XML to describe the build process and its dependencies, whereas make has its
Makefile format. By default the XML file is named build.xml.
Ant is an Apache project. It is open source software, and is released under the
Apache Software License.
History
Ant was conceived by James Duncan Davidson while turning a product from Sun into
open source. That product, Sun's reference JSP/Servlet engine, later became
Apache Tomcat. A proprietary version of make was used to build it on the Solaris
Operating Environment, but in the open source world there was no way of
controlling which platform was used to build Tomcat. Ant was created as a
simple, platform-independent tool to build Tomcat from directives in an XML
"build file". From this humble beginning, the tool has gone on to become more
widespread - and perhaps more successful - than the Tomcat product for which it
was created. Ant (version 1.1) was officially released as a stand-alone product
on July 19, 2000. It has become the underpinning of open source Java; developers
expect a "build.xml" file with every project.
Because Ant made it trivial to integrate JUnit tests with the build process, Ant
has made it easy for willing developers to adopt test-driven development, and
even Extreme Programming.
Other Java-based build tools include Maven and JavaMake.
The name is an acronym for "Another Neat Tool".
Sample build.xml file
Below is listed a sample build.xml file for a simple Java "Hello, world"
application. It defines four targets - clean, clobber, compile and jar, each of
which has an associated description. The jar target lists the compile target as
a dependency. This tells Ant that before it can start the jar target it must
first complete the compile target.
<?xml version="1.0"?>
<project name="Hello" default="compile">
<target name="clean" description="remove intermediate files">
<delete dir="classes"/>
</target>
<target name="clobber" depends="clean" description="remove all artifact files">
<delete file="hello.jar"/>
</target>
<target name="compile" description="compile the Java source code to class
files">
<mkdir dir="classes"/>
<javac srcdir="." destdir="classes"/>
</target>
<target name="jar" depends="compile" description="create a Jar file for the
application">
<jar destfile="hello.jar">
<fileset dir="classes" includes="**/*.class"/>
<manifest>
<attribute name="Main-Class" value="HelloProgram"/>
</manifest>
</jar>
</target>
</project>
Within each target are the actions that Ant must take to build that target;
these are performed using built-in tasks. For example, to build the compile
target Ant must first create a directory called classes (Ant will only do so if
it does not already exist) and then invoke the Java compiler. Therefore, the
tasks used are mkdir and javac. These perform a similar task to the command-line
utilities of the same name.
Another task used in this example is named jar:
<jar destfile="hello.jar">
This ant task has the same name as the common java command-line utility, JAR,
but is really a call to the ant program's built in jar/zip file support. This
detail is not relevant to most end users, who just get the JAR they wanted, with
the files they asked for.
Many Ant tasks delegate their work to external programs, either native or Java.
They use Ant's own <exec> and <java> tasks to set up the command lines, and
handle all the details of mapping from information in the build file to the
program's arguments -and interpreting the return value. Users can see which
tasks do this (e.g <cvs>, <signjar>, <chmod>, <rpm>), by trying to execute the
task on a system without the underlying program on the path, or without a full
Java Development Kit (JDK) installed.
Extensions
WOProject-Ant is just one of many examples of a task extension written for ant.
These extensions are put to use by copying their jar files into ant's lib
directory. Once this is done, these extension tasks can be invoked directly in
the typical build.xml file. The WOProject extensions allow WebObjects developers
to use ant in building their frameworks and applications, instead of using
Apple's Xcode suite.
Antcontrib provides a collection of tasks such as conditional statements and
operations on properties as well as other useful tasks.
Other task extensions exist for Perforce, .Net, EJB, filesystem manipulations,
just to name a few.
Portability
One of the primary aims of Ant was to solve make's portability problems. In a
Makefile the actions required to create a target are specified as shell commands
which are specific to the current platform, usually a Unix shell. Ant solves
this problem by providing a large amount of built-in functionality which it can
then guarantee will behave (nearly) identically on all platforms.
For example, in the sample build.xml file above the clean target deletes the
classes directory and everything in it. In a Makefile this would typically be
done with the command:
rm -rf classes/
rm is a Unix specific command which will probably not be available if the
Makefile is used in a non-Unix environment such as Microsoft Windows. In an Ant
build file the same thing would be accomplished using a built in command:
<delete dir="classes"/>
A common discrepancy between different platforms is the way in which directory
paths are specified. Unix uses a forward slash (/) to delimit the components of
a path, whereas Windows uses a backslash (\). Ant build files let authors choose
their favorite convention, forward slashes or back slashes for directories,
semicolon or colon for path separators. It converts everything to the
appropriate format for the current platform.
Limitations
* Ant build files are written in XML. For unfamiliar users, both XML itself and
the complex structure (hierarchical, partly ordered, and pervasively
cross-linked) of Ant documents can be a barrier to learning. A GUI called
Antidote was available for a time, but never gained a following and has been
retired from the Apache project. Moreover, the language Ant uses is quite
verbose and the build files of large or complex projects become unmanageably
large; good design and modularization of build files can improve readability but
not reduce size. Other build tools like Maven use more concise scripts at the
expense of generality and flexibility.
* Many of the older tasks—the core ones that are used every day, such as
<javac>, <exec> and <java>—use default values for options that are not
consistent with more recent tasks. Changing those defaults would break existing
tasks.
* When expanding properties in a string or text element, undefined properties
are not raised as an error, but left as an unexpanded reference (e.g.
${unassigned.property}).
* Ant has limited fault handling rules, and no persistence of state, so it
cannot be used as a workflow tool for any workflow other than classic build and
test processes.
* The Ant target model does not treat artifacts as targets. In most build tools
a target is an artifact created by the build -- a program, library, intermediate
object file, PDF documentation, etc. -- and rules specify the dependencies
between targets and the tasks to run to build a target when it is out of date.
In Ant a target is a group of tasks rather than an artifact. This means that Ant
is sometimes unable to determine the relationship between an artifact and the
task sequence to build the artifact and this logic must be implemented by the
programmer using Ant's control structures.
* Once a property is defined it cannot be changed by any of the core tasks.
Antcontrib provides a variable task to go around this problem.
* Reuse of build file fragment is hard. Ant1.7 makes it easier, with <import>
and <macrodef>, but this does run the risk of providing even more complexity for
new Ant users to get into trouble with.
Contact Information
Call our office today to set up an appointment. Learn more about how we can
help you, and learn more about the other services that we can offer you. All
messages we receive will be answered as soon as possible. We look forward to
hearing from you.
- Electronic mail
- General Information:
