On Windows, if we are going to link with a shared module, we need the
implib.
Use case: The Xorg server builds some X protocol extensions as modules. The
implibs for these modules need to be shipped as part of the SDK, to enable
building of 3rd party extensions which reference symbols in (and hence on
Windows, need to be linked with) these modules.
Refine #3277
According to what I read on the internet, on OSX, both MH_BUNDLE (module)
and MH_DYLIB (shared library) can be dynamically loaded using dlopen(), but
it is not possible to link against MH_BUNDLE as if they were shared
libraries.
Metion this as an issue in the documentation.
Emitting a warning, and then going on to fail during the build with
mysterious errors in symbolextractor isn't very helpful, so make attempting
this an error on OSX.
Add a test for that.
See also:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htmhttps://stackoverflow.com/questions/2339679/what-are-the-differences-between-so-and-dylib-on-osx
debugoptimized builds building against Qt would ultimately link against
both the debug and non-debug msvcrt, ntdll, etc libraries which causes
crashes in weird places and is very much not recommended by Microsoft.
This changes the selected Qt library(ies) correctly to not uses the
debug variants for debugoptimized builds.
https://github.com/mesonbuild/meson/pull/3680
Without this, building a module in a Flatpak app manifest that is a
newer version of a module already present in the Flatpak runtime will
fail. (The Flatpak file system is a bunch of hard links to readonly
files, which can be replaced but not written to.)
This instead creates a temporary file in the same directory as the
destination (to avoid cross-device renaming errors) and atomically
renames the temporary file to the destination, replacing it instead of
rewriting it as shutil.copyfile() would do.
If only 1 dir is provided, the 2nd defaults to '.' and if none is
provided they default to '.' and '..'. It should be builddir first,
followed by sourcedir, but validate_core_dirs() will still swap them if
builddir contains a meson.build file.
This simplifies a lot of code, and centralize "key=value" parsing in a
single place.
Unknown command line options becomes an hard error instead of
merely printing warning message. It has been warning it would become an
hard error for a while now. This has exceptions though, any
unknown option starting with "<lang>_" or "b_" are ignored because they
depend on which languages gets added and which compiler gets selected.
Also any option for unknown subproject are ignored because they depend
on which subproject actually gets built.
Also write more command line parsing tests. "19 bad command line
options" is removed because bad cmd line option became hard error and
it's covered with new tests in "30 command line".
All options are now the projectoptions list, regardless of how they got
defined in the command line.
This also delays setting builtin option values until the main project()
default options are parsed to simplify the code. This is possible
because we already delayed setting the backend after parsing main
project() in a previous commit.
This ensure all option groups are printed the same way. Also ensure that
we cannot miss some builtin options by taking the list of all builtin
options and excluding only directories/testing options.
The project() function could have a different value for the backend
option in its default_options kwargs.
Also set backend options, passing them in command line had no effect
previously.
It is nicer to early raise exception if the value from meson_options.txt
is not a string in "[]" format than duplicating the parser code for both
cases.
Also it was checking for duplicated items only in the user_input case,
but we should also check for dups in the default value from
meson_options.txt.
The 'Platform' envvar may not be set on Visual Studio 2008, at least
when using the SDK 7.0 compilers, so check the 'BUILD_PLAT' envvar so
that we do not mis-detect x64 build environments as x86.
This reverts commit 0045d95a16.
<jeandet> nirbheek, it seems 0045d95a16 is
really wrong, I've tested on Ubuntu. While writing this line I was
thinking that you can't have Qt without a working qmake in the path. On
Ubuntu you have that qtchooser stuff which is misleading.
Normally, people would just pass -fembed-bitcode in CFLAGS, but this
conflicts with -Wl,-dead_strip_dylibs and -bundle, so we need it as
an option so that those can be quietly disabled.
Traceback (most recent call last):
File "meson.py", line 29, in <module>
sys.exit(mesonmain.main())
File "mesonbuild/mesonmain.py", line 411, in main
return run(sys.argv[1:], launcher)
File "mesonbuild/mesonmain.py", line 320, in run
return mintro.run(remaining_args)
File "mesonbuild/mintro.py", line 234, in run
list_installed(installdata)
File "mesonbuild/mintro.py", line 72, in list_installed
for path, installdir, aliases, unknown1, unknown2 in installdata.targets:
ValueError: too many values to unpack (expected 5)
When the exe runner is `wine` or `wine32` or `wine64`, etc.
This allows people to run tests with wine.
Note that you also have to set WINEPATH to point to your custom
prefix(es) if your tests use external dependencies.
Closes https://github.com/mesonbuild/meson/issues/3620
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
Nirbheek Chauhan
Jon Turney
Matthew Waters
Xavier Claessens
Philip Chimento
Chun-wei Fan
Niklas Claesson
Aleksey Filippov
mikolajp