@@ -126,14 +126,26 @@ cmake --build build --target check
126
126
` --target ` can be spelled ` -t ` in CMake 3.15+. You can also run individual
127
127
tests with these targets:
128
128
129
- * ` pytest ` : Python tests only
129
+ * ` pytest ` : Python tests only, using the
130
+ [ pytest] ( https://docs.pytest.org/en/stable/ ) framework
130
131
* ` cpptest ` : C++ tests only
131
132
* ` test_cmake_build ` : Install / subdirectory tests
132
133
133
134
If you want to build just a subset of tests, use
134
135
` -DPYBIND11_TEST_OVERRIDE="test_callbacks.cpp;test_pickling.cpp" ` . If this is
135
136
empty, all tests will be built.
136
137
138
+ You may also pass flags to the ` pytest ` target by editing ` tests/pytest.ini ` or
139
+ by using the ` PYTEST_ADDOPTS ` environment variable
140
+ (see [ ` pytest ` docs] ( https://docs.pytest.org/en/2.7.3/customize.html#adding-default-options ) ). As an example:
141
+
142
+ ``` bash
143
+ env PYTEST_ADDOPTS=" --capture=no --exitfirst" \
144
+ cmake --build build --target pytest
145
+ # Or using abbreviated flags
146
+ env PYTEST_ADDOPTS=" -s -x" cmake --build build --target pytest
147
+ ```
148
+
137
149
### Formatting
138
150
139
151
All formatting is handled by pre-commit.
@@ -164,7 +176,182 @@ name, pre-commit):
164
176
pre-commit install
165
177
```
166
178
179
+ ### Clang-Format
180
+
181
+ As of v2.6.2, pybind11 ships with a [ ` clang-format ` ] [ clang-format ]
182
+ configuration file at the top level of the repo (the filename is
183
+ ` .clang-format ` ). Currently, formatting is NOT applied automatically, but
184
+ manually using ` clang-format ` for newly developed files is highly encouraged.
185
+ To check if a file needs formatting:
186
+
187
+ ``` bash
188
+ clang-format -style=file --dry-run some.cpp
189
+ ```
190
+
191
+ The output will show things to be fixed, if any. To actually format the file:
192
+
193
+ ``` bash
194
+ clang-format -style=file -i some.cpp
195
+ ```
196
+
197
+ Note that the ` -style-file ` option searches the parent directories for the
198
+ ` .clang-format ` file, i.e. the commands above can be run in any subdirectory
199
+ of the pybind11 repo.
200
+
201
+ ### Clang-Tidy
202
+
203
+ [ ` clang-tidy ` ] [ clang-tidy ] performs deeper static code analyses and is
204
+ more complex to run, compared to ` clang-format ` , but support for ` clang-tidy `
205
+ is built into the pybind11 CMake configuration. To run ` clang-tidy ` , the
206
+ following recipe should work. Files will be modified in place, so you can
207
+ use git to monitor the changes.
208
+
209
+ ``` bash
210
+ docker run --rm -v $PWD :/pybind11 -it silkeh/clang:10
211
+ apt-get update && apt-get install python3-dev python3-pytest
212
+ cmake -S pybind11/ -B build -DCMAKE_CXX_CLANG_TIDY=" $( which clang-tidy) ;-fix"
213
+ cmake --build build
214
+ ```
215
+
216
+ ### Include what you use
217
+
218
+ To run include what you use, install (` brew install include-what-you-use ` on
219
+ macOS), then run:
220
+
221
+ ``` bash
222
+ cmake -S . -B build-iwyu -DCMAKE_CXX_INCLUDE_WHAT_YOU_USE=$( which include-what-you-use)
223
+ cmake --build build
224
+ ```
225
+
226
+ The report is sent to stderr; you can pipe it into a file if you wish.
227
+
228
+ ### Build recipes
229
+
230
+ This builds with the Intel compiler (assuming it is in your path, along with a
231
+ recent CMake and Python 3):
232
+
233
+ ``` bash
234
+ python3 -m venv venv
235
+ . venv/bin/activate
236
+ pip install pytest
237
+ cmake -S . -B build-intel -DCMAKE_CXX_COMPILER=$( which icpc) -DDOWNLOAD_CATCH=ON -DDOWNLOAD_EIGEN=ON -DPYBIND11_WERROR=ON
238
+ ```
239
+
240
+ This will test the PGI compilers:
241
+
242
+ ``` bash
243
+ docker run --rm -it -v $PWD :/pybind11 nvcr.io/hpc/pgi-compilers:ce
244
+ apt-get update && apt-get install -y python3-dev python3-pip python3-pytest
245
+ wget -qO- " https://cmake.org/files/v3.18/cmake-3.18.2-Linux-x86_64.tar.gz" | tar --strip-components=1 -xz -C /usr/local
246
+ cmake -S pybind11/ -B build
247
+ cmake --build build
248
+ ```
249
+
250
+ ### Explanation of the SDist/wheel building design
251
+
252
+ > These details below are _ only_ for packaging the Python sources from git. The
253
+ > SDists and wheels created do not have any extra requirements at all and are
254
+ > completely normal.
255
+
256
+ The main objective of the packaging system is to create SDists (Python's source
257
+ distribution packages) and wheels (Python's binary distribution packages) that
258
+ include everything that is needed to work with pybind11, and which can be
259
+ installed without any additional dependencies. This is more complex than it
260
+ appears: in order to support CMake as a first class language even when using
261
+ the PyPI package, they must include the _ generated_ CMake files (so as not to
262
+ require CMake when installing the ` pybind11 ` package itself). They should also
263
+ provide the option to install to the "standard" location
264
+ (` <ENVROOT>/include/pybind11 ` and ` <ENVROOT>/share/cmake/pybind11 ` ) so they are
265
+ easy to find with CMake, but this can cause problems if you are not an
266
+ environment or using `` pyproject.toml `` requirements. This was solved by having
267
+ two packages; the "nice" pybind11 package that stores the includes and CMake
268
+ files inside the package, that you get access to via functions in the package,
269
+ and a ` pybind11-global ` package that can be included via ` pybind11[global] ` if
270
+ you want the more invasive but discoverable file locations.
271
+
272
+ If you want to install or package the GitHub source, it is best to have Pip 10
273
+ or newer on Windows, macOS, or Linux (manylinux1 compatible, includes most
274
+ distributions). You can then build the SDists, or run any procedure that makes
275
+ SDists internally, like making wheels or installing.
276
+
277
+
278
+ ``` bash
279
+ # Editable development install example
280
+ python3 -m pip install -e .
281
+ ```
282
+
283
+ Since Pip itself does not have an ` sdist ` command (it does have ` wheel ` and
284
+ ` install ` ), you may want to use the upcoming ` build ` package:
285
+
286
+ ``` bash
287
+ python3 -m pip install build
288
+
289
+ # Normal package
290
+ python3 -m build -s .
291
+
292
+ # Global extra
293
+ PYBIND11_GLOBAL_SDIST=1 python3 -m build -s .
294
+ ```
295
+
296
+ If you want to use the classic "direct" usage of ` python setup.py ` , you will
297
+ need CMake 3.15+ and either ` make ` or ` ninja ` preinstalled (possibly via `pip
298
+ install cmake ninja` ), since directly running Python on ` setup.py` cannot pick
299
+ up and install ` pyproject.toml ` requirements. As long as you have those two
300
+ things, though, everything works the way you would expect:
301
+
302
+ ``` bash
303
+ # Normal package
304
+ python3 setup.py sdist
305
+
306
+ # Global extra
307
+ PYBIND11_GLOBAL_SDIST=1 python3 setup.py sdist
308
+ ```
309
+
310
+ A detailed explanation of the build procedure design for developers wanting to
311
+ work on or maintain the packaging system is as follows:
312
+
313
+ #### 1. Building from the source directory
314
+
315
+ When you invoke any ` setup.py ` command from the source directory, including
316
+ ` pip wheel . ` and ` pip install . ` , you will activate a full source build. This
317
+ is made of the following steps:
318
+
319
+ 1 . If the tool is PEP 518 compliant, like Pip 10+, it will create a temporary
320
+ virtual environment and install the build requirements (mostly CMake) into
321
+ it. (if you are not on Windows, macOS, or a manylinux compliant system, you
322
+ can disable this with ` --no-build-isolation ` as long as you have CMake 3.15+
323
+ installed)
324
+ 2 . The environment variable ` PYBIND11_GLOBAL_SDIST ` is checked - if it is set
325
+ and truthy, this will be make the accessory ` pybind11-global ` package,
326
+ instead of the normal ` pybind11 ` package. This package is used for
327
+ installing the files directly to your environment root directory, using
328
+ ` pybind11[global] ` .
329
+ 2 . ` setup.py ` reads the version from ` pybind11/_version.py ` and verifies it
330
+ matches ` includes/pybind11/detail/common.h ` .
331
+ 3 . CMake is run with ` -DCMAKE_INSTALL_PREIFX=pybind11 ` . Since the CMake install
332
+ procedure uses only relative paths and is identical on all platforms, these
333
+ files are valid as long as they stay in the correct relative position to the
334
+ includes. ` pybind11/share/cmake/pybind11 ` has the CMake files, and
335
+ ` pybind11/include ` has the includes. The build directory is discarded.
336
+ 4 . Simpler files are placed in the SDist: ` tools/setup_*.py.in ` ,
337
+ ` tools/pyproject.toml ` (` main ` or ` global ` )
338
+ 5 . The package is created by running the setup function in the
339
+ ` tools/setup_*.py ` . ` setup_main.py ` fills in Python packages, and
340
+ ` setup_global.py ` fills in only the data/header slots.
341
+ 6 . A context manager cleans up the temporary CMake install directory (even if
342
+ an error is thrown).
343
+
344
+ ### 2. Building from SDist
345
+
346
+ Since the SDist has the rendered template files in ` tools ` along with the
347
+ includes and CMake files in the correct locations, the builds are completely
348
+ trivial and simple. No extra requirements are required. You can even use Pip 9
349
+ if you really want to.
350
+
351
+
167
352
[ pre-commit ] : https://pre-commit.com
353
+ [ clang-format ] : https://clang.llvm.org/docs/ClangFormat.html
354
+ [ clang-tidy ] : https://clang.llvm.org/extra/clang-tidy/
168
355
[ pybind11.readthedocs.org ] : http://pybind11.readthedocs.org/en/latest
169
356
[ issue tracker ] : https://github.com/pybind/pybind11/issues
170
357
[ gitter ] : https://gitter.im/pybind/Lobby
0 commit comments