Fix get_library_dirs() on FreeBSD to only return /usr/local/lib,
/usr/lib and /lib as the default location to look for libraries.
FreeBSD does not use lib/${platform} or lib64 by default. In general,
those directories should not exist, but in case they do, ensure they're
not picked up.
Fix defaul_libdir() on FreeBSD. The current behaviour of using
usr/lib64 if that exists is wrong on FreeBSD. The default should be to
always use usr/lib, even if usr/lib64 exists as a folder in the file
system. Fix this by checking if we're running on FreeBSD and then
always return 'lib' in default_libdir().
This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
'c_arg' entries should become *both* compiler options and external
peprocessor options for C. (And likewise for a few other languages.)
Seems inconsistent to me, but this is the status quo.
In addition to MSVC, which was worked around previously, GCC also does
not list includes from the PCH in the depfile by default, unless
-fpch-deps is given. I think it's best to stay safe and not rely on any
particular behavior from the compiler here.
Also adds test case for shared library linking.
Closes#4912, at least on Linux. The future 0.50.0 does not yet claim to
support CUDA on systems other than Linux and backends other than Ninja.
Pre/PostBuildEvents do not run if no other build steps are out-of-date.
For most run targets (including install and test) that have no other
build steps, VS considers these to be always up-to-date after they have
been built once.
On the other hand, CustomBuild has clearly defined inputs and outputs
that define whether the target is up-to-date or not. By using a
nonexistent file as output of CustomBuild, it is always considered
out-of-date.
This aligns the VS behavior with ninja. `ninja install` unconditionally
installs, `ninja test` always runs the tests, and a run target always
gets executed, without any checks whether it is up-to-date or not.
Previously, this was only added to C/C++ targets, but not for others.
Thus, if you'd change a setting through `meson configure`, this was not
picked up, e.g. the install target said it was up-to-date and when force
rebuilding it, it also did not use the new settings until the build dir
was manually reconfigured.
Mypy struggles with the imperative form of Enum declaration, and
upstream doesn't consider it a bug, they recomend using the class form
for enums that are going to be externally exposed.