@@ -177,38 +177,27 @@ strategies for folding a library built in a subproject into a wheel built with
177177 to be within the Python package's tree, or rely on ``meson-python `` to fold
178178 it into the wheel when it'd otherwise be installed to ``libdir ``.
179179
180- Option (1) tends to be easier, so unless the library of interest cannot be
181- built as a static library or it would inflate the wheel size too much because
182- it's needed by multiple Python extension modules, we recommend trying option
183- (1) first.
184-
185- A typical C or C++ project providing a library to link against tends to provide
186- (a) one or more ``library() `` targets, which can be built as shared, static, or both,
187- and (b) headers, pkg-config files, tests and perhaps other development targets
188- that are needed to use the ``library() `` target(s). One of the challenges to use
189- such projects as a subproject is that the headers and other installable targets
190- are targeting system locations (e.g., ``<prefix>/include/ ``) which isn't supported
191- by wheels and hence ``meson-python `` errors out when it encounters such an install
192- target. This is perhaps the main issue one encounters with subproject usage,
193- and the following two sections discuss how options (1) and (2) can work around
194- that.
180+ Static linking tends to be easier, and it is the recommended solution, unless
181+ the library of interest cannot be built as a static library or it would
182+ inflate the wheel size too much because it's needed by multiple Python
183+ extension modules.
195184
196185Static library from subproject
197186------------------------------
198187
199- The major advantage of building a library target as static and folding it directly
200- into an extension module is that no targets from the subproject need to be installed.
201- To configure the subproject for this use case, add the following to the
202- ``pyproject.toml `` file of your package:
188+ The major advantage of building a library target as static and folding it
189+ directly into an extension module is that the RPATH or the DLL search path do
190+ not need to be adjusted and no targets from the subproject need to be
191+ installed. To ensures that ``library() `` targets are built as static, and that
192+ no parts of the subprojects are installed, the following configuration can be
193+ added in ``pyproject.toml `` to ensure the relevant options are passed to Meson:
203194
204195.. code-block :: toml
205196
206197 [tool.meson-python.args]
207198 setup = ['--default-library=static']
208199 install = ['--skip-subprojects']
209200
210- This ensures that ``library `` targets are built as static, and nothing gets installed.
211-
212201 To then link against the static library in the subproject, say for a subproject
213202named ``bar `` with the main library target contained in a ``bar_dep `` dependency,
214203add this to your ``meson.build `` file:
@@ -225,30 +214,37 @@ add this to your ``meson.build`` file:
225214 install: true,
226215 )
227216
228- That is all!
229-
230217 Shared library from subproject
231218------------------------------
232219
233- If we can't use the static library approach from the section above and we need
234- a shared library, then we must have ``install: true `` for that shared library
235- target. This can only work if we can pass some build option to the subproject
236- that tells it to *only * install the shared library and not headers or other
237- targets that we don't need. Install tags don't work per subproject, so
238- this will look something like:
220+ Sometimes it may be necessary or preferable to use dynamic linking to a shared
221+ library provided in a subproject, for example to avoid inflating the wheel
222+ size having multiple copies of the same object code in different extension
223+ modules using the same library. In this case, the subproject needs to install
224+ the shared library in the usual location in ``libdir ``. ``meson-python ``
225+ will automatically include it into the wheel in
226+ ``.<project-name>.mesonpy.libs `` just like an internal shared library.
227+
228+ Most projects, however, install more than the shared library and the extra
229+ components, such as header files or documentation, should not be included in
230+ the Python wheel. Projects may have configuration options to disable building
231+ and installing additional components, in this case, these options can be
232+ passed to the ``subproject() `` call:
239233
240234.. code-block :: meson
241235
242236 foo_subproj = subproject('foo',
243237 default_options: {
244- # This is a custom option - if it doesn't exist, can you add it
245- # upstream or in WrapDB?
246- 'only_install_main_lib': true,
238+ 'docs': 'disabled',
247239 })
248240 foo_dep = foo_subproj.get_variable('foo_dep')
249241
250- Now we can use ``foo_dep `` like a normal dependency, ``meson-python `` will
251- include it into the wheel in ``.<project-name>.mesonpy.libs `` just like an
252- internal shared library that targets ``libdir `` (see
253- :ref: `internal-shared-libraries `).
254- *Remember: this method doesn't support Windows (yet)! *
242+ Install tags do not work per subproject, therefore to exclude other parts of
243+ the subproject form being included in the wheel, we need to resort to
244+ ``meson-python `` install location filters using the
245+ :option: `tool.meson-python.wheel.exclude ` build option:
246+
247+ .. code-block :: toml
248+
249+ [tool.meson-python.wheel]
250+ exclude = ['{prefix}/include/*']
0 commit comments