| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
build scripts
… rather than as an extra step after `cargo doc`.
This helps always using the correct set of CSS properties
(for layout 2013 v.s. 2020).
|
| |
|
|
| |
style crate
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This will eventually need to be done for #1908
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Cleanup/refactor build scripts for DOM codegen
Prior to this commit, the script codegen makefile relied on an
intermediary pythonpath.py file that handled python dependencies and
incorporated a couple hacks to get the codegen building working. This
commit removes that intermediary file and attempts to make the script
codegen build process cleaner.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7209)
<!-- Reviewable:end -->
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Prior to this commit, the script codegen makefile relied on an
intermediary pythonpath.py file that handled python dependencies and
incorporated a couple hacks to get the codegen building working. This
commit removes that intermediary file and attempts to make the script
codegen build process cleaner.
|
| | | |
|
| |/
|
|
| |
In some of these cases, files were not being closed
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
As per this conversation:
https://github.com/servo/servo/pull/6580
|
| |
|
