1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465 |
- 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) is only supported during the parse phase. Any attempt to recursively expand
- an $(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.
- 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)
|