@@ -187,38 +187,27 @@ strategies for folding a library built in a subproject into a wheel built with
187187 to be within the Python package's tree, or rely on ``meson-python `` to fold
188188 it into the wheel when it'd otherwise be installed to ``libdir ``.
189189
190- Option (1) tends to be easier, so unless the library of interest cannot be
191- built as a static library or it would inflate the wheel size too much because
192- it's needed by multiple Python extension modules, we recommend trying option
193- (1) first.
194-
195- A typical C or C++ project providing a library to link against tends to provide
196- (a) one or more ``library() `` targets, which can be built as shared, static, or both,
197- and (b) headers, pkg-config files, tests and perhaps other development targets
198- that are needed to use the ``library() `` target(s). One of the challenges to use
199- such projects as a subproject is that the headers and other installable targets
200- are targeting system locations (e.g., ``<prefix>/include/ ``) which isn't supported
201- by wheels and hence ``meson-python `` errors out when it encounters such an install
202- target. This is perhaps the main issue one encounters with subproject usage,
203- and the following two sections discuss how options (1) and (2) can work around
204- that.
190+ Static linking tends to be easier, and it is the recommended solution, unless
191+ the library of interest cannot be built as a static library or it would
192+ inflate the wheel size too much because it's needed by multiple Python
193+ extension modules.
205194
206195Static library from subproject
207196------------------------------
208197
209- The major advantage of building a library target as static and folding it directly
210- into an extension module is that no targets from the subproject need to be installed.
211- To configure the subproject for this use case, add the following to the
212- ``pyproject.toml `` file of your package:
198+ The major advantage of building a library target as static and folding it
199+ directly into an extension module is that the RPATH or the DLL search path do
200+ not need to be adjusted and no targets from the subproject need to be
201+ installed. To ensures that ``library() `` targets are built as static, and that
202+ no parts of the subprojects are installed, the following configuration can be
203+ added in ``pyproject.toml `` to ensure the relevant options are passed to Meson:
213204
214205.. code-block :: toml
215206
216207 [tool.meson-python.args]
217208 setup = ['--default-library=static']
218209 install = ['--skip-subprojects']
219210
220- This ensures that ``library `` targets are built as static, and nothing gets installed.
221-
222211 To then link against the static library in the subproject, say for a subproject
223212named ``bar `` with the main library target contained in a ``bar_dep `` dependency,
224213add this to your ``meson.build `` file:
@@ -235,30 +224,37 @@ add this to your ``meson.build`` file:
235224 install: true,
236225 )
237226
238- That is all!
239-
240227 Shared library from subproject
241228------------------------------
242229
243- If we can't use the static library approach from the section above and we need
244- a shared library, then we must have ``install: true `` for that shared library
245- target. This can only work if we can pass some build option to the subproject
246- that tells it to *only * install the shared library and not headers or other
247- targets that we don't need. Install tags don't work per subproject, so
248- this will look something like:
230+ Sometimes it may be necessary or preferable to use dynamic linking to a shared
231+ library provided in a subproject, for example to avoid inflating the wheel
232+ size having multiple copies of the same object code in different extension
233+ modules using the same library. In this case, the subproject needs to install
234+ the shared library in the usual location in ``libdir ``. ``meson-python ``
235+ will automatically include it into the wheel in
236+ ``.<project-name>.mesonpy.libs `` just like an internal shared library.
237+
238+ Most projects, however, install more than the shared library and the extra
239+ components, such as header files or documentation, should not be included in
240+ the Python wheel. Projects may have configuration options to disable building
241+ and installing additional components, in this case, these options can be
242+ passed to the ``subproject() `` call:
249243
250244.. code-block :: meson
251245
252246 foo_subproj = subproject('foo',
253247 default_options: {
254- # This is a custom option - if it doesn't exist, can you add it
255- # upstream or in WrapDB?
256- 'only_install_main_lib': true,
248+ 'docs': 'disabled',
257249 })
258250 foo_dep = foo_subproj.get_variable('foo_dep')
259251
260- Now we can use ``foo_dep `` like a normal dependency, ``meson-python `` will
261- include it into the wheel in ``.<project-name>.mesonpy.libs `` just like an
262- internal shared library that targets ``libdir `` (see
263- :ref: `internal-shared-libraries `).
264- *Remember: this method doesn't support Windows (yet)! *
252+ Install tags do not work per subproject, therefore to exclude other parts of
253+ the subproject form being included in the wheel, we need to resort to
254+ ``meson-python `` install location filters using the
255+ :option: `tool.meson-python.wheel.exclude ` build option:
256+
257+ .. code-block :: toml
258+
259+ [tool.meson-python.wheel]
260+ exclude = ['{prefix}/include/*']
0 commit comments