build/pymake/README

Wed, 31 Dec 2014 07:16:47 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Wed, 31 Dec 2014 07:16:47 +0100
branch
TOR_BUG_9701
changeset 3
141e0f1194b1
permissions
-rw-r--r--

Revert simplistic fix pending revisit of Mozilla integration attempt.

michael@0 1 INTRODUCTION
michael@0 2
michael@0 3 make.py (and the pymake modules that support it) are an implementation of the make tool
michael@0 4 which are mostly compatible with makefiles written for GNU make.
michael@0 5
michael@0 6 PURPOSE
michael@0 7
michael@0 8 The Mozilla project inspired this tool with several goals:
michael@0 9
michael@0 10 * Improve build speeds, especially on Windows. This can be done by reducing the total number
michael@0 11 of processes that are launched, especially MSYS shell processes which are expensive.
michael@0 12
michael@0 13 * Allow writing some complicated build logic directly in Python instead of in shell.
michael@0 14
michael@0 15 * Allow computing dependencies for special targets, such as members within ZIP files.
michael@0 16
michael@0 17 * Enable experiments with build system. By writing a makefile parser, we can experiment
michael@0 18 with converting in-tree makefiles to another build system, such as SCons, waf, ant, ...insert
michael@0 19 your favorite build tool here. Or we could experiment along the lines of makepp, keeping
michael@0 20 our existing makefiles, but change the engine to build a global dependency graph.
michael@0 21
michael@0 22 KNOWN INCOMPATIBILITIES
michael@0 23
michael@0 24 * Order-only prerequisites are not yet supported
michael@0 25
michael@0 26 * Secondary expansion is not yet supported.
michael@0 27
michael@0 28 * Target-specific variables behave differently than in GNU make: in pymake, the target-specific
michael@0 29 variable only applies to the specific target that is mentioned, and does not apply recursively
michael@0 30 to all dependencies which are remade. This is an intentional change: the behavior of GNU make
michael@0 31 is neither deterministic nor intuitive.
michael@0 32
michael@0 33 * $(eval) is only supported during the parse phase. Any attempt to recursively expand
michael@0 34 an $(eval) function during command execution will fail. This is an intentional incompatibility.
michael@0 35
michael@0 36 * There is a subtle difference in execution order that can cause unexpected changes in the
michael@0 37 following circumstance:
michael@0 38 ** A file `foo.c` exists on the VPATH
michael@0 39 ** A rule for `foo.c` exists with a dependency on `tool` and no commands
michael@0 40 ** `tool` is remade for some other reason earlier in the file
michael@0 41 In this case, pymake resets the VPATH of `foo.c`, while GNU make does not. This shouldn't
michael@0 42 happen in the real world, since a target found on the VPATH without commands is silly. But
michael@0 43 mozilla/js/src happens to have a rule, which I'm patching.
michael@0 44
michael@0 45 * pymake does not implement any of the builtin implicit rules or the related variables. Mozilla
michael@0 46 only cares because pymake doesn't implicitly define $(RM), which I'm also fixing in the Mozilla
michael@0 47 code.
michael@0 48
michael@0 49 ISSUES
michael@0 50
michael@0 51 * Speed is a problem.
michael@0 52
michael@0 53 FUTURE WORK
michael@0 54
michael@0 55 * implement a new type of command which is implemented in python. This would allow us
michael@0 56 to replace the current `nsinstall` binary (and execution costs for the shell and binary) with an
michael@0 57 in-process python solution.
michael@0 58
michael@0 59 AUTHOR
michael@0 60
michael@0 61 Initial code was written by Benjamin Smedberg <benjamin@smedbergs.us>. For future releases see
michael@0 62 http://benjamin.smedbergs.us/pymake/
michael@0 63
michael@0 64 See the LICENSE file for license information (MIT license)

mercurial