aboutsummaryrefslogtreecommitdiffstats
path: root/components/script/dom/bindings/codegen/BindingGen.py
Commit message (Collapse)AuthorAgeFilesLines
* WebIDL codegen: Replace cmake with a single Python scriptSimon Sapin2019-09-271-54/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | When playing around with Cargo’s new timing visualization: https://internals.rust-lang.org/t/exploring-crate-graph-build-times-with-cargo-build-ztimings/10975/21 … I was surprised to see the `script` crate’s build script take 76 seconds. I did not expect WebIDL bindings generation to be *that* computationally intensive. It turns out almost all of this time is overhead. The build script uses CMake to generate bindings for each WebIDL file in parallel, but that causes a lot of work to be repeated 366 times: * Starting up a Python VM * Importing (parts of) the Python standard library * Importing ~16k lines of our Python code * Recompiling the latter to bytecode, since we used `python -B` to disable writing `.pyc` file * Deserializing with `cPickle` and recreating in memory the results of parsing all WebIDL files ---- This commit remove the use of CMake and cPickle for the `script` crate. Instead, all WebIDL bindings generation is done sequentially in a single Python process. This takes 2 to 3 seconds.
* Update MPL license to https (part 3)Jan Andre Ikenmeyer2018-11-191-1/+1
|
* Remove unused command-line Python codegen argumentsCorey Farwell2016-01-071-2/+0
|
* Do not create modules from files with nothing to codegen (fixes #8711)Anthony Ramine2015-12-161-2/+4
|
* Use OS-agnostic filesystem paths in PythonCorey Farwell2015-09-081-2/+2
| | | | This will eventually need to be done for #1908
* Allow 'script' component to enter a 'built' stateCorey Farwell2015-09-021-5/+7
| | | | | | | | | | | | | After this pull request merged: https://github.com/servo/servo/pull/7209 the 'script' component would never enter a 'built' state. In other words, if one calls `mach build`, lets it complete, then calls `mach build` again, the 'script' component would rebuild even though we supposedly just built it. This was due to the `ParserResults.pkl` getting placed in the `components/script` directory instead of the output directory, causing cargo to think that there were unbuilt files.
* Utilize Python context managers for opening/closing filesCorey Farwell2015-08-211-3/+2
| | | | In some of these cases, files were not being closed
* Remove tidy blacklist for 'script/dom/bindings/*'Corey Farwell2015-07-091-5/+6
| | | | | | | | | | | | | | | | | | | | | Recently, I found myself reading through the Python codegen scripts that live in 'components/script/dom/bindings/*' and noticed that there were many tidy violations: unnecessary semicolons, weird spacing, unused variables, lack of license headers, etc. Considering these files are now living in our tree and mostly maintained directly by contributors of Servo (as opposed to being from upstream), I feel these files should not be excluded from our normal tidy process. This commit removes the blacklist on these files and fixes all tidy violations. I added these subdirectories to the blacklist because they appear to be maintained upstream somewhere else: * "components/script/dom/bindings/codegen/parser/*", * "components/script/dom/bindings/codegen/ply/*", Also, I added a '# noqa' comment which tells us to ignore the flake8 errors for that line. I chose to ignore this (instead of fixing it) to make the work for this commit simpler for me.
* Cargoify servoJack Moffitt2014-09-081-0/+52