@@ -86,10 +86,10 @@ $ cargo build --features testing_only_docs
86
86
87
87
### Overview
88
88
89
- Input C/C++ test headers reside in the ` tests/headers ` directory. Expected
90
- output Rust bindings live in ` tests/expectations/tests ` . For example,
91
- ` tests/headers/my_header.h ` 's expected generated Rust bindings would be
92
- ` tests/expectations/tests/my_header.rs ` .
89
+ Input C/C++ test headers reside in the ` bindgen-tests/ tests/headers` directory. Expected
90
+ output Rust bindings live in ` bindgen-tests/ tests/expectations/tests` . For example,
91
+ ` bindgen-tests/ tests/headers/my_header.h` 's expected generated Rust bindings would be
92
+ ` bindgen-tests/ tests/expectations/tests/my_header.rs` .
93
93
94
94
There are also some integration tests in the ` ./bindgen-integration ` crate, which uses ` bindgen ` to
95
95
generate bindings to some C++ code, and then uses the bindings, asserting that
@@ -109,8 +109,8 @@ These steps must be performed manually when needed.
109
109
110
110
### Testing Bindings Generation
111
111
112
- To regenerate bindings from the corpus of test headers in ` tests/headers ` and
113
- compare them against the expected bindings in ` tests/expectations/tests ` , run:
112
+ To regenerate bindings from the corpus of test headers in ` bindgen-tests/ tests/headers` and
113
+ compare them against the expected bindings in ` bindgen-tests/ tests/expectations/tests` , run:
114
114
115
115
```
116
116
$ cargo test
@@ -139,14 +139,14 @@ those.
139
139
### Testing Generated Bindings
140
140
141
141
If your local changes are introducing expected modifications in the
142
- ` tests/expectations/tests/* ` bindings files, then you should test that the
142
+ ` bindgen-tests/ tests/expectations/tests/*` bindings files, then you should test that the
143
143
generated bindings files still compile, and that their struct layout tests still
144
144
pass. Also, run the integration tests (see below).
145
145
146
146
You can do this with these commands:
147
147
148
148
```
149
- $ cd tests/expectations
149
+ $ cd bindgen-tests/ tests/expectations
150
150
$ cargo test
151
151
```
152
152
@@ -157,22 +157,22 @@ is a dependency for running `test-one.sh`.
157
157
158
158
Sometimes its useful to work with one test header from start (generating
159
159
bindings for it) to finish (compiling the bindings and running their layout
160
- tests). This can be done with the ` tests/test-one.sh ` script. It supports fuzzy
160
+ tests). This can be done with the ` bindgen-tests/ tests/test-one.sh` script. It supports fuzzy
161
161
searching for test headers. For example, to test
162
162
` tests/headers/what_is_going_on.hpp ` , execute this command:
163
163
164
164
```
165
- $ ./tests/test-one.sh going
165
+ $ ./bindgen-tests/ tests/test-one.sh going
166
166
```
167
167
168
168
Note that ` test-one.sh ` does not recompile ` bindgen ` , so if you change the code,
169
169
you'll need to rebuild it before running the script again.
170
170
171
171
### Authoring New Tests
172
172
173
- To add a new test header to the suite, simply put it in the ` tests/headers `
173
+ To add a new test header to the suite, simply put it in the ` bindgen-tests/ tests/headers`
174
174
directory. Next, run ` bindgen ` to generate the initial expected output Rust
175
- bindings. Put those in ` tests/expectations/tests ` .
175
+ bindings. Put those in ` bindgen-tests/ tests/expectations/tests` .
176
176
177
177
If your new test requires certain flags to be passed to ` bindgen ` , you can
178
178
specify them at the top of the test header, with a comment like this:
@@ -186,7 +186,7 @@ specify them at the top of the test header, with a comment like this:
186
186
Then verify the new Rust bindings compile and pass their layout tests:
187
187
188
188
```
189
- $ cd tests/expectations
189
+ $ cd bindgen-tests/ tests/expectations
190
190
$ cargo test new_test_header
191
191
```
192
192
@@ -195,11 +195,11 @@ $ cargo test new_test_header
195
195
If a test generates different bindings across different ` libclang ` versions (for
196
196
example, because we take advantage of better/newer APIs when possible), then you
197
197
can add multiple test expectations, one for each supported ` libclang `
198
- version. Instead of having a single ` tests/expectations/tests/my_test.rs ` file,
198
+ version. Instead of having a single ` bindgen-tests/ tests/expectations/tests/my_test.rs` file,
199
199
add each of:
200
200
201
- * ` tests/expectations/tests/libclang-9/my_test.rs `
202
- * ` tests/expectations/tests/libclang-5/my_test.rs `
201
+ * ` bindgen-tests/ tests/expectations/tests/libclang-9/my_test.rs`
202
+ * ` bindgen-tests/ tests/expectations/tests/libclang-5/my_test.rs`
203
203
204
204
If you need to update the test expectations for a test file that generates
205
205
different bindings for different ` libclang ` versions, you * don't* need to have
0 commit comments