ok/jj
1
0
Fork 0
forked from mirrors/jj
Commit graph

6 commits

Author SHA1 Message Date
Martin von Zweigbergk
b94c78545b protos: use run_from_script() in build.rs
`run_from_script()` is effectively the same as we did with `.expect()`
(print the error to stderr and exit with an error).
2022-05-05 11:46:40 -07:00
Martin von Zweigbergk
a59724b082 protos: move .proto files to more conventional src/protos/ 2022-05-05 11:46:40 -07:00
Martin von Zweigbergk
ffc57310f6 cargo: upgrade protobuf crates to 3.0.1
The biggest difference in the API is that fields are now public. The
exception from that is `oneof` fields, which still require setters and
getters.

I couldn't measure any difference in performance. I didn't expect any
difference either, but it's good that it didn't seem to regress. I
timed `jj debug operation <some hash prefix>`, which will read the
whole operation log (to check that the prefix is unambiguous).
2022-05-04 17:02:11 -07:00
Waleed Khan
9202aae8b1 build: conditionally use map_first_last feature if available 2022-02-20 22:21:14 -08:00
Martin von Zweigbergk
4b8484e561 rustfmt: configure to group imports 2021-03-14 10:46:25 -07:00
Martin von Zweigbergk
c7ee24727a protobuf: generate code at build-time
I had tried to generate the protobuf code at build time many months
ago, but decided against it because it slowed down the build too
much. I didn't realize there was the
"cargo:rerun-if-changed=<filename>" feature that time. Given that that
exists, it seems like an obvious win to generate the source code at
build time.

I put the generated sources in `$OUT_DIR` (where [1] says they should
be), then include them in the `protos` module by using the `include!`
macro. The biggest problem with that is that I couldn't get IntelliJ
to understand it, even after enabling the experimental features
described in [2].

 [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation

 [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865
2020-12-24 01:05:17 -08:00