summaryrefslogtreecommitdiff
path: root/docs/markdown/Dependencies.md
blob: d95b8359dda35d4efde96c493be1c7c27c790a73 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
---
short-description: Dependencies for external libraries and frameworks
...

# Dependencies

Very few applications are fully self-contained, but rather they use
external libraries and frameworks to do their work. Meson makes it
very easy to find and use external dependencies. Here is how one would
use the zlib compression library.

```meson
zdep = dependency('zlib', version : '>=1.2.8')
exe = executable('zlibprog', 'prog.c', dependencies : zdep)
```

First Meson is told to find the external library `zlib` and error out
if it is not found. The `version` keyword is optional and specifies a
version requirement for the dependency. Then an executable is built
using the specified dependency. Note how the user does not need to
manually handle compiler or linker flags or deal with any other
minutiae.

If you have multiple dependencies, pass them as an array:

```meson
executable('manydeps', 'file.c', dependencies : [dep1, dep2, dep3, dep4])
```

If the dependency is optional, you can tell Meson not to error out if
the dependency is not found and then do further configuration.

```meson
opt_dep = dependency('somedep', required : false)
if opt_dep.found()
  # Do something.
else
  # Do something else.
endif
```

You can pass the `opt_dep` variable to target construction functions
whether the actual dependency was found or not. Meson will ignore
non-found dependencies.

Meson also allows to get variables that are defined in the
`pkg-config` file. This can be done by using the
[[dep.get_pkgconfig_variable]] function.

```meson
zdep_prefix = zdep.get_pkgconfig_variable('prefix')
```

These variables can also be redefined by passing the `define_variable`
parameter, which might be useful in certain situations:

```meson
zdep_prefix = zdep.get_pkgconfig_variable('libdir', define_variable: ['prefix', '/tmp'])
```

The dependency detector works with all libraries that provide a
`pkg-config` file. Unfortunately several packages don't provide
pkg-config files. Meson has autodetection support for some of these,
and they are described [later in this
page](#dependencies-with-custom-lookup-functionality).

# Arbitrary variables from dependencies that can be found multiple ways

*Note* new in 0.51.0
*new in 0.54.0, the `internal` keyword*

When you need to get an arbitrary variables from a dependency that can
be found multiple ways and you don't want to constrain the type you
can use the generic `get_variable` method. This currently supports
cmake, pkg-config, and config-tool based variables.

```meson
foo_dep = dependency('foo')
var = foo_dep.get_variable(cmake : 'CMAKE_VAR', pkgconfig : 'pkg-config-var', configtool : 'get-var', default_value : 'default')
```

It accepts the keywords 'cmake', 'pkgconfig', 'pkgconfig_define',
'configtool', 'internal', and 'default_value'. 'pkgconfig_define'
works just like the 'define_variable' argument to
`get_pkgconfig_variable`. When this method is invoked the keyword
corresponding to the underlying type of the dependency will be used to
look for a variable. If that variable cannot be found or if the caller
does not provide an argument for the type of dependency, one of the
following will happen: If 'default_value' was provided that value will
be returned, if 'default_value' was not provided then an error will be
raised.

## Dependencies that provide resource files

Sometimes a dependency provides installable files which other projects then
need to use. For example, wayland-protocols XML files.

```meson
foo_dep = dependency('foo')
foo_datadir = foo_dep.get_variable('pkgdatadir')
custom_target(
    'foo-generated.c',
    input: foo_datadir / 'prototype.xml',
    output: 'foo-generated.c',
    command: [generator, '@INPUT@', '@OUTPUT@']
)
```

*Since 0.63.0* these actually work as expected, even when they come from a
(well-formed) internal dependency. This only works when treating the files to
be obtained as interchangeable with a system dependency -- e.g. only public
files may be used, and leaving the directory pointed to by the dependency is
not allowed.

# Declaring your own

You can declare your own dependency objects that can be used
interchangeably with dependency objects obtained from the system. The
syntax is straightforward:

```meson
my_inc = include_directories(...)
my_lib = static_library(...)
my_dep = declare_dependency(link_with : my_lib,
  include_directories : my_inc)
```

This declares a dependency that adds the given include directories and
static library to any target you use it in.

# Building dependencies as subprojects

Many platforms do not provide a system package manager. On these
systems dependencies must be compiled from source. Meson's subprojects
make it simple to use system dependencies when they are available and
to build dependencies manually when they are not.

To make this work, the dependency must have Meson build definitions
and it must declare its own dependency like this:

```meson
    foo_dep = declare_dependency(...)
```

Then any project that wants to use it can write out the following
declaration in their main `meson.build` file.

```meson
    foo_dep = dependency('foo', fallback : ['foo', 'foo_dep'])
```

What this declaration means is that first Meson tries to look up the
dependency from the system (such as by using pkg-config). If it is not
available, then it builds subproject named `foo` and from that
extracts a variable `foo_dep`. That means that the return value of
this function is either an external or an internal dependency object.
Since they can be used interchangeably, the rest of the build
definitions do not need to care which one it is. Meson will take care
of all the work behind the scenes to make this work.

# Dependency detection method

You can use the keyword `method` to let Meson know what method to use
when searching for the dependency. The default value is `auto`.
Additional methods are `pkg-config`, `config-tool`, `cmake`,
`builtin`, `system`, `sysconfig`, `qmake`, `extraframework` and `dub`.

```meson
cups_dep = dependency('cups', method : 'pkg-config')
```

For dependencies without [specific detection
logic](#dependencies-with-custom-lookup-functionality), the dependency method
order for `auto` is:

  1. `pkg-config`
  2. `cmake`
  3. `extraframework` (OSX only)

## System

Some dependencies provide no valid methods for discovery, or do so only in
some cases. Some examples of this are Zlib, which provides both pkg-config
and cmake, except when it is part of the base OS image (such as in FreeBSD
and macOS); OpenGL which has pkg-config on Unices from glvnd or mesa, but has
no pkg-config on macOS and Windows.

In these cases Meson provides convenience wrappers in the form of `system`
dependencies. Internally these dependencies do exactly what a user would do
in the build system DSL or with a script, likely calling
[[compiler.find_library]], setting `link_with` and `include_directories`. By
putting these in Meson upstream the barrier of using them is lowered, as
projects using Meson don't have to re-implement the logic.

## Builtin

Some dependencies provide no valid methods for discovery on some systems,
because they are provided internally by the language. One example of this is
intl, which is built into GNU or musl libc but otherwise comes as a `system`
dependency.

In these cases Meson provides convenience wrappers for the `system` dependency,
but first checks if the functionality is usable by default.

## CMake

Meson can use the CMake `find_package()` function to detect
dependencies with the builtin `Find<NAME>.cmake` modules and exported
project configurations (usually in `/usr/lib/cmake`). Meson is able to
use both the old-style `<NAME>_LIBRARIES` variables as well as
imported targets.

It is possible to manually specify a list of CMake targets that should
be used with the `modules` property. However, this step is optional
since Meson tries to automatically guess the correct target based on
the name of the dependency.

Depending on the dependency it may be necessary to explicitly specify
a CMake target with the `modules` property if Meson is unable to guess
it automatically.

```meson
    cmake_dep = dependency('ZLIB', method : 'cmake', modules : ['ZLIB::ZLIB'])
```

Support for adding additional `COMPONENTS` for the CMake
`find_package` lookup is provided with the `components` kwarg
(*introduced in 0.54.0*). All specified components will be passed
directly to `find_package(COMPONENTS)`.

Support for packages which require a specified version for CMake
`find_package` to succeed is provided with the `cmake_package_version`
kwarg (*introduced in 0.57.0*). The specified `cmake_package_version`
will be passed directly as the second parameter to `find_package`.

It is also possible to reuse existing `Find<name>.cmake` files with the
`cmake_module_path` property (*since 0.50.0*). Using this property is
equivalent to setting the `CMAKE_MODULE_PATH` variable in CMake. The
path(s) given to `cmake_module_path` should all be relative to the
project source directory. Absolute paths should only be used if the
CMake files are not stored in the project itself.

Additional CMake parameters can be specified with the `cmake_args`
property (*since 0.50.0*).

## Dub

Please understand that Meson is only able to find dependencies that
exist in the local Dub repository. You need to manually fetch and
build the target dependencies.

For `urld`.
```
dub fetch urld
dub build urld
```

Other thing you need to keep in mind is that both Meson and Dub need
to be using the same compiler. This can be achieved using Dub's
`-compiler` argument and/or manually setting the `DC` environment
variable when running Meson.
```
dub build urld --compiler=dmd
DC="dmd" meson setup builddir
```

## Config tool

[CUPS](#cups), [LLVM](#llvm), [pcap](#pcap), [WxWidgets](#wxwidgets),
[libwmf](#libwmf), [GCrypt](#libgcrypt), [GPGME](#gpgme), and GnuStep either do not provide pkg-config
modules or additionally can be detected via a config tool
(cups-config, llvm-config, libgcrypt-config, etc). Meson has native support for these
tools, and they can be found like other dependencies:

```meson
pcap_dep = dependency('pcap', version : '>=1.0')
cups_dep = dependency('cups', version : '>=1.4')
llvm_dep = dependency('llvm', version : '>=4.0')
libgcrypt_dep = dependency('libgcrypt', version: '>= 1.8')
gpgme_dep = dependency('gpgme', version: '>= 1.0')
```

*Since 0.55.0* Meson won't search $PATH any more for a config tool
binary when cross compiling if the config tool did not have an entry
in the cross file.

# Dependencies with custom lookup functionality

Some dependencies have specific detection logic.

Generic dependency names are case-sensitive<sup>[1](#footnote1)</sup>,
but these dependency names are matched case-insensitively. The
recommended style is to write them in all lower-case.

In some cases, more than one detection method exists, and the `method`
keyword may be used to select a detection method to use. The `auto`
method uses any checking mechanisms in whatever order Meson thinks is
best.

e.g. libwmf and CUPS provide both pkg-config and config-tool support.
You can force one or another via the `method` keyword:

```meson
cups_dep = dependency('cups', method : 'pkg-config')
wmf_dep = dependency('libwmf', method : 'config-tool')
```

## AppleFrameworks

Use the `modules` keyword to list frameworks required, e.g.

```meson
dep = dependency('appleframeworks', modules : 'foundation')
```

These dependencies can never be found for non-OSX hosts.

## Blocks

Enable support for Clang's blocks extension.

```meson
dep = dependency('blocks')
```

*(added 0.52.0)*

## Boost

Boost is not a single dependency but rather a group of different
libraries. To use Boost headers-only libraries, simply add Boost as a
dependency.

```meson
boost_dep = dependency('boost')
exe = executable('myprog', 'file.cc', dependencies : boost_dep)
```

To link against boost with Meson, simply list which libraries you
would like to use.

```meson
boost_dep = dependency('boost', modules : ['thread', 'utility'])
exe = executable('myprog', 'file.cc', dependencies : boost_dep)
```

You can call [[dependency]] multiple times with different modules and
use those to link against your targets.

If your boost headers or libraries are in non-standard locations you
can set the `BOOST_ROOT`, or the `BOOST_INCLUDEDIR` and
`BOOST_LIBRARYDIR` environment variables. *(added in 0.56.0)* You can
also set these parameters as `boost_root`, `boost_include`, and
`boost_librarydir` in your native or cross machine file. Note that
machine file variables are preferred to environment variables, and
that specifying any of these disables system-wide search for boost.

You can set the argument `threading` to `single` to use boost
libraries that have been compiled for single-threaded use instead.

## CUDA

*(added 0.53.0)*

Enables compiling and linking against the CUDA Toolkit. The `version`
and `modules` keywords may be passed to request the use of a specific
CUDA Toolkit version and/or additional CUDA libraries, correspondingly:

```meson
dep = dependency('cuda', version : '>=10', modules : ['cublas'])
```

Note that explicitly adding this dependency is only necessary if you are
using CUDA Toolkit from a C/C++ file or project, or if you are utilizing
additional toolkit libraries that need to be explicitly linked to. If the
CUDA Toolkit cannot be found in the default paths on your system, you can
set the path using `CUDA_PATH` explicitly.

## CUPS

`method` may be `auto`, `config-tool`, `pkg-config`, `cmake` or `extraframework`.

## Curses

*(Since 0.54.0)*

Curses (and ncurses) are a cross platform pain in the butt. Meson
wraps up these dependencies in the `curses` dependency. This covers
both `ncurses` (preferred) and other curses implementations.

`method` may be `auto`, `pkg-config`, `config-tool`, or `system`.

*New in 0.56.0* The `config-tool` and `system` methods.

To define some of the preprocessor symbols mentioned in the
[curses autoconf documentation](http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_with_curses.m4):

```meson
conf = configuration_data()
check_headers = [
  ['ncursesw/menu.h', 'HAVE_NCURSESW_MENU_H'],
  ['ncurses/menu.h', 'HAVE_NCURSES_MENU_H'],
  ['menu.h', 'HAVE_MENU_H'],
  ['ncursesw/curses.h', 'HAVE_NCURSESW_CURSES_H'],
  ['ncursesw.h', 'HAVE_NCURSESW_H'],
  ['ncurses/curses.h', 'HAVE_NCURSES_CURSES_H'],
  ['ncurses.h', 'HAVE_NCURSES_H'],
  ['curses.h', 'HAVE_CURSES_H'],
]

foreach h : check_headers
  if compiler.has_header(h.get(0))
    conf.set(h.get(1), 1)
  endif
endforeach
```

## dl (libdl)

*(added 0.62.0)*

Provides access to the dynamic link interface (functions: dlopen,
dlclose, dlsym and others). On systems where this is not built
into libc (mostly glibc < 2.34), tries to find an external library
providing them instead.

`method` may be `auto`, `builtin` or `system`.

## Fortran Coarrays

*(added 0.50.0)*

 Coarrays are a Fortran language intrinsic feature, enabled by
`dependency('coarray')`.

GCC will use OpenCoarrays if present to implement coarrays, while Intel and NAG
use internal coarray support.

## GPGME

*(added 0.51.0)*

`method` may be `auto`, `config-tool` or `pkg-config`.

## GL

This finds the OpenGL library in a way appropriate to the platform.

`method` may be `auto`, `pkg-config` or `system`.

## GTest and GMock

GTest and GMock come as sources that must be compiled as part of your
project. With Meson you don't have to care about the details, just
pass `gtest` or `gmock` to `dependency` and it will do everything for
you. If you want to use GMock, it is recommended to use GTest as well,
as getting it to work standalone is tricky.

You can set the `main` keyword argument to `true` to use the `main()`
function provided by GTest:

```meson
gtest_dep = dependency('gtest', main : true, required : false)
e = executable('testprog', 'test.cc', dependencies : gtest_dep)
test('gtest test', e)
```

## HDF5

*(added 0.50.0)*

HDF5 is supported for C, C++ and Fortran. Because dependencies are
language-specific, you must specify the requested language using the
`language` keyword argument, i.e.,
 * `dependency('hdf5', language: 'c')` for the C HDF5 headers and libraries
 * `dependency('hdf5', language: 'cpp')` for the C++ HDF5 headers and libraries
 * `dependency('hdf5', language: 'fortran')` for the Fortran HDF5 headers and libraries

Meson uses pkg-config to find HDF5. The standard low-level HDF5
function and the `HL` high-level HDF5 functions are linked for each
language.

`method` may be `auto`, `config-tool` or `pkg-config`.

*New in 0.56.0* the `config-tool` method.
*New in 0.56.0* the dependencies now return proper dependency types
 and `get_variable` and similar methods should work as expected.

## iconv

*(added 0.60.0)*

Provides access to the `iconv` family of C functions. On systems where this is
not built into libc, tries to find an external library providing them instead.

`method` may be `auto`, `builtin` or `system`.

## intl

*(added 0.59.0)*

Provides access to the `*gettext` family of C functions. On systems where this
is not built into libc, tries to find an external library providing them
instead.

`method` may be `auto`, `builtin` or `system`.

## JDK

*(added 0.58.0)*
*(deprecated 0.62.0)*

Deprecated name for JNI. `dependency('jdk')` instead of `dependency('jni')`.

## JNI

*(added 0.62.0)*

`modules` is an optional list of strings containing any of `jvm` and `awt`.

Provides access to compiling with the Java Native Interface (JNI). The lookup
will first check if `JAVA_HOME` is set in the environment, and if not will use
the resolved path of `javac`. Systems will usually link your preferred JDK to
well known paths like `/usr/bin/javac` on Linux for instance. Using the path
from `JAVA_HOME` or the resolved `javac`, this dependency will place the JDK
installation's `include` directory and its platform-dependent subdirectory on
the compiler's include path. If `modules` is non-empty, then the proper linker
arguments will also be added.

```meson
dep = dependency('jni', version: '>= 1.8.0', modules: ['jvm'])
```

**Note**: Due to usage of a resolved path, upgrading the JDK may cause the
various paths to not be found. In that case, please reconfigure the build
directory. One workaround is to explicitly set `JAVA_HOME` instead of relying on
the fallback `javac` resolved path behavior.

**Note**: Include paths might be broken on platforms other than `linux`,
`windows`, `darwin`, and `sunos`. Please submit a PR or open an issue in this
case.

**Note**: Use of the `modules` argument on a JDK `<= 1.8` may be broken if your
system is anything other than `x86_64`. Please submit a PR or open an issue in
this case.

## libgcrypt

*(added 0.49.0)*

`method` may be `auto`, `config-tool` or `pkg-config`.

## libwmf

*(added 0.44.0)*

`method` may be `auto`, `config-tool` or `pkg-config`.

## LLVM

Meson has native support for LLVM going back to version LLVM version
3.5. It supports a few additional features compared to other
config-tool based dependencies.

As of 0.44.0 Meson supports the `static` keyword argument for LLVM.
Before this LLVM >= 3.9 would always dynamically link, while older
versions would statically link, due to a quirk in `llvm-config`.

`method` may be `auto`, `config-tool`, or `cmake`.

### Modules, a.k.a. Components

Meson wraps LLVM's concept of components in its own modules concept.
When you need specific components you add them as modules as Meson
will do the right thing:

```meson
llvm_dep = dependency('llvm', version : '>= 4.0', modules : ['amdgpu'])
```

As of 0.44.0 it can also take optional modules (these will affect the arguments
generated for a static link):

```meson
llvm_dep = dependency(
  'llvm', version : '>= 4.0', modules : ['amdgpu'], optional_modules : ['inteljitevents'],
)
```

### Using LLVM tools

When using LLVM as library but also needing its tools, it is often
beneficial to use the same version. This can partially be achieved
with the `version` argument of `find_program()`. However,
distributions tend to package different LLVM versions in rather
different ways. Therefore, it is often better to use the llvm
dependency directly to retrieve the tools:

```meson
llvm_dep = dependency('llvm', version : ['>= 8', '< 9'])
llvm_link = find_program(llvm_dep.get_variable(configtool: 'bindir') / 'llvm-link')
```

## MPI

*(added 0.42.0)*

MPI is supported for C, C++ and Fortran. Because dependencies are
language-specific, you must specify the requested language using the
`language` keyword argument, i.e.,
 * `dependency('mpi', language: 'c')` for the C MPI headers and libraries
 * `dependency('mpi', language: 'cpp')` for the C++ MPI headers and libraries
 * `dependency('mpi', language: 'fortran')` for the Fortran MPI headers and libraries

Meson prefers pkg-config for MPI, but if your MPI implementation does
not provide them, it will search for the standard wrapper executables,
`mpic`, `mpicxx`, `mpic++`, `mpifort`, `mpif90`, `mpif77`. If these
are not in your path, they can be specified by setting the standard
environment variables `MPICC`, `MPICXX`, `MPIFC`, `MPIF90`, or
`MPIF77`, during configuration. It will also try to use the Microsoft
implementation on windows via the `system` method.

`method` may be `auto`, `config-tool`, `pkg-config` or `system`.

*New in 0.54.0* The `config-tool` and `system` method values. Previous
versions would always try `pkg-config`, then `config-tool`, then `system`.

## NetCDF

*(added 0.50.0)*

NetCDF is supported for C, C++ and Fortran. Because NetCDF dependencies are
language-specific, you must specify the requested language using the
`language` keyword argument, i.e.,
 * `dependency('netcdf', language: 'c')` for the C NetCDF headers and libraries
 * `dependency('netcdf', language: 'cpp')` for the C++ NetCDF headers and libraries
 * `dependency('netcdf', language: 'fortran')` for the Fortran NetCDF headers and libraries

Meson uses pkg-config to find NetCDF.

## OpenMP

*(added 0.46.0)*

This dependency selects the appropriate compiler flags and/or libraries to use
for OpenMP support.

The `language` keyword may used.

## OpenSSL

*(added 0.62.0)*

`method` may be `auto`, `pkg-config`, `system` or `cmake`.

## pcap

*(added 0.42.0)*

`method` may be `auto`, `config-tool` or `pkg-config`.

## Pybind11

*(added 1.1.0)*

`method` may be `auto`, `pkg-config`, `config-tool`, or `cmake`.

## Python3

Python3 is handled specially by Meson:
1. Meson tries to use `pkg-config`.
2. If `pkg-config` fails Meson uses a fallback:
    - On Windows the fallback is the current `python3` interpreter.
    - On OSX the fallback is a framework dependency from `/Library/Frameworks`.

Note that `python3` found by this dependency might differ from the one
used in `python3` module because modules uses the current interpreter,
but dependency tries `pkg-config` first.

`method` may be `auto`, `extraframework`, `pkg-config` or `sysconfig`

## Qt4 & Qt5

Meson has native Qt support. Its usage is best demonstrated with an
example.

```meson
qt5_mod = import('qt5')
qt5widgets = dependency('qt5', modules : 'Widgets')

processed = qt5_mod.preprocess(
  moc_headers : 'mainWindow.h',   # Only headers that need moc should be put here
  moc_sources : 'helperFile.cpp', # must have #include"moc_helperFile.cpp"
  ui_files    : 'mainWindow.ui',
  qresources  : 'resources.qrc',
)

q5exe = executable('qt5test',
  sources     : ['main.cpp',
                 'mainWindow.cpp',
                 processed],
  dependencies: qt5widgets)
```

Here we have an UI file created with Qt Designer and one source and
header file each that require preprocessing with the `moc` tool. We
also define a resource file to be compiled with `rcc`. We just have to
tell Meson which files are which and it will take care of invoking all
the necessary tools in the correct order, which is done with the
`preprocess` method of the `qt5` module. Its output is simply put in
the list of sources for the target. The `modules` keyword of
`dependency` works just like it does with Boost. It tells which
subparts of Qt the program uses.

You can set the `main` keyword argument to `true` to use the
`WinMain()` function provided by qtmain static library (this argument
does nothing on platforms other than Windows).

Setting the optional `private_headers` keyword to true adds the
private header include path of the given module(s) to the compiler
flags. (since v0.47.0)

**Note** using private headers in your project is a bad idea, do so at
your own risk.

`method` may be `auto`, `pkg-config` or `qmake`.

## SDL2

SDL2 can be located using `pkg-confg`, the `sdl2-config` config tool,
or as an OSX framework.

`method` may be `auto`, `config-tool`, `extraframework` or
`pkg-config`.

## Shaderc

*(added 0.51.0)*

Meson will first attempt to find shaderc using `pkg-config`. Upstream
currently ships three different `pkg-config` files and by default will
check them in this order: `shaderc`, `shaderc_combined`, and
`shaderc_static`. If the `static` keyword argument is `true`, then
Meson instead checks in this order: `shaderc_combined`, `shaderc_static`,
and `shaderc`.

If no `pkg-config` file is found, then Meson will try to detect the
library manually. In this case, it will try to link against either
`-lshaderc_shared` or `-lshaderc_combined`, preferring the latter
if the static keyword argument is true. Note that it is not possible
to obtain the shaderc version using this method.

`method` may be `auto`, `pkg-config` or `system`.

## Threads

This dependency selects the appropriate compiler flags and/or
libraries to use for thread support.

See [threads](Threads.md).

## Valgrind

Meson will find valgrind using `pkg-config`, but only uses the
compilation flags and avoids trying to link with its non-PIC static
libs.

## Vulkan

*(added 0.42.0)*

Vulkan can be located using `pkg-config`, or the `VULKAN_SDK`
environment variable.

`method` may be `auto`, `pkg-config` or `system`.

## WxWidgets

Similar to [Boost](#boost), WxWidgets is not a single library but rather
a collection of modules. WxWidgets is supported via `wx-config`.
Meson substitutes `modules` to `wx-config` invocation, it generates
- `compile_args` using `wx-config --cxxflags $modules...`
- `link_args` using `wx-config --libs $modules...`

### Example

```meson
wx_dep = dependency(
  'wxwidgets', version : '>=3.0.0', modules : ['std', 'stc'],
)
```

```shell
# compile_args:
$ wx-config --cxxflags std stc

# link_args:
$ wx-config --libs std stc
```

## Zlib

Zlib ships with pkg-config and cmake support, but on some operating
systems (windows, macOs, FreeBSD, dragonflybsd, android), it is provided as
part of the base operating system without pkg-config support. The new
System finder can be used on these OSes to link with the bundled
version.

`method` may be `auto`, `pkg-config`, `cmake`, or `system`.

*New in 0.54.0* the `system` method.

<hr>
<a name="footnote1">1</a>: They may appear to be case-insensitive, if the
    underlying file system happens to be case-insensitive.