https://github.com/mozilla/pymake

INACTIVE - http://mzl.la/ghe-archive - make implementation in Python
https://github.com/mozilla/pymake

inactive unmaintained

Last synced: 23 days ago
JSON representation

INACTIVE - http://mzl.la/ghe-archive - make implementation in Python

• Host: GitHub
• URL: https://github.com/mozilla/pymake
• Owner: mozilla
• License: mit
• Archived: true
• Created: 2014-06-25T22:17:03.000Z (over 10 years ago)
• Default Branch: master
• Last Pushed: 2019-03-29T04:59:20.000Z (over 5 years ago)
• Last Synced: 2024-10-29T10:01:37.493Z (about 1 month ago)
• Topics: inactive, unmaintained
• Language: Python
• Size: 2.35 MB
• Stars: 80
• Watchers: 12
• Forks: 32
• Open Issues: 0
• Metadata Files:
  • Readme: README
  • License: LICENSE

Awesome Lists containing this project

• starred-awesome - pymake - make implementation in Python (Python)

README

        
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 . For future releases see

http://benjamin.smedbergs.us/pymake/

See the LICENSE file for license information (MIT license)