make.py (and the pymake modules that support it) are an implementation of the make tool
which are mostly compatible with makefiles written for GNU make.
PURPOSE
The Mozilla project inspired this tool with several goals:
Improve build speeds, especially on Windows. This can be done by reducing the total number
of processes that are launched, especially MSYS shell processes which are expensive.
Allow writing some complicated build logic directly in Python instead of in shell.
Allow computing dependencies for special targets, such as members within ZIP files.
Enable experiments with build system. By writing a makefile parser, we can experiment
with converting in-tree makefiles to another build system, such as SCons, waf, ant, …insert
your favorite build tool here. Or we could experiment along the lines of makepp, keeping
our existing makefiles, but change the engine to build a global dependency graph.
KNOWN INCOMPATIBILITIES
Order-only prerequisites are not yet supported
Secondary expansion is not yet supported.
Target-specific variables behave differently than in GNU make: in pymake, the target-specific
variable only applies to the specific target that is mentioned, and does not apply recursively
to all dependencies which are remade. This is an intentional change: the behavior of GNU make
is neither deterministic nor intuitive.
(eval)isonlysupportedduringtheparsephase.Anyattempttorecursivelyexpandan(eval) function during command execution will fail. This is an intentional incompatibility.
There is a subtle difference in execution order that can cause unexpected changes in the
following circumstance:
A file foo.c exists on the VPATH
A rule for foo.c exists with a dependency on tool and no commands
tool is remade for some other reason earlier in the file
In this case, pymake resets the VPATH of foo.c, while GNU make does not. This shouldn’t
happen in the real world, since a target found on the VPATH without commands is silly. But
mozilla/js/src happens to have a rule, which I’m patching.
pymake does not implement any of the builtin implicit rules or the related variables. Mozilla
only cares because pymake doesn’t implicitly define $(RM), which I’m also fixing in the Mozilla
code.
ISSUES
Speed is a problem.
FUTURE WORK
implement a new type of command which is implemented in python. This would allow us
to replace the current nsinstall binary (and execution costs for the shell and binary) with an
in-process python solution.
INTRODUCTION
make.py (and the pymake modules that support it) are an implementation of the make tool which are mostly compatible with makefiles written for GNU make.
PURPOSE
The Mozilla project inspired this tool with several goals:
Improve build speeds, especially on Windows. This can be done by reducing the total number of processes that are launched, especially MSYS shell processes which are expensive.
Allow writing some complicated build logic directly in Python instead of in shell.
Allow computing dependencies for special targets, such as members within ZIP files.
Enable experiments with build system. By writing a makefile parser, we can experiment with converting in-tree makefiles to another build system, such as SCons, waf, ant, …insert your favorite build tool here. Or we could experiment along the lines of makepp, keeping our existing makefiles, but change the engine to build a global dependency graph.
KNOWN INCOMPATIBILITIES
Order-only prerequisites are not yet supported
Secondary expansion is not yet supported.
Target-specific variables behave differently than in GNU make: in pymake, the target-specific variable only applies to the specific target that is mentioned, and does not apply recursively to all dependencies which are remade. This is an intentional change: the behavior of GNU make is neither deterministic nor intuitive.
(eval)isonlysupportedduringtheparsephase.Anyattempttorecursivelyexpandan(eval) function during command execution will fail. This is an intentional incompatibility.
There is a subtle difference in execution order that can cause unexpected changes in the following circumstance:
foo.cexists on the VPATHfoo.cexists with a dependency ontooland no commandstoolis remade for some other reason earlier in the file In this case, pymake resets the VPATH offoo.c, while GNU make does not. This shouldn’t happen in the real world, since a target found on the VPATH without commands is silly. But mozilla/js/src happens to have a rule, which I’m patching.pymake does not implement any of the builtin implicit rules or the related variables. Mozilla only cares because pymake doesn’t implicitly define $(RM), which I’m also fixing in the Mozilla code.
ISSUES
FUTURE WORK
nsinstallbinary (and execution costs for the shell and binary) with an in-process python solution.AUTHOR
Initial code was written by Benjamin Smedberg benjamin@smedbergs.us. For future releases see http://benjamin.smedbergs.us/pymake/
See the LICENSE file for license information (MIT license)