Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
q.v. dependencies/__init__.py#L41
|
|
|
|
|
|
|
|
|
|
Also add a section how to deal with file encodings.
|
|
Input files can be in any file encoding, not just utf-8 or isolatin1. Meson
should not make assumptions here and allow for the user to specify the
encoding to use.
|
|
Closes: #3712
|
|
e.g. 'meson x86_64-w64-mingw32 --cross-file x86_64-w64-mingw32' currently
fails with an IsADirectoryError exception.
Cross files must be files, so when searching, only accept a candidate path
which is an existing file, not just an existing path.
|
|
|
|
|
|
|
|
A new custom_install_mode element was added in 05c43cdcd
|
|
Extended from the test case in #3575.
This exercises File objects and string filenames for the same resource
script filename at different paths.
|
|
|
|
|
|
We reuse the same function for generating PATH, and we don't want to
exclude system paths there for obvious reasons.
|
|
Otherwise we can end up searching for the same library tens of times,
because pkg-config does not de-duplicate -lfoo args before returning
them.
We use -Wl,--start-group/end-group, so we do not need to worry about
ordering issues in static libraries.
|
|
Lookup the library paths using the available compilers instead.
This makes the code work on non-Linux platforms too.
|
|
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.htm
https://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
|
|
Closes: #3700.
|
|
|
|
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.
|
|
|
|
That dict gets modified when adding default_options, but mesonmain will
need to keep the original values.
|
|
|
|
Closes #3456.
|
|
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".
|
|
self.init() raise an exception so anything else in the 'with' block is
not executed.
|
|
This also means we don't need to keep original command line arguments
anymore.
|
|
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.
|
|
|
|
|
|
set_value() is implemented by the base class, subclasses only need to
override validate_value().
|
|
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.
|
|
|
|
|
|
These are the last remaining places where attributes set by argparse for
"--builtin-option" are used.
|
|
This is also more consistent with the error message returned by
optinterpreter when it finds unknown command line options.
|
|
Those methods only use coredata object, so better just move them as a
coredata method.
|
|
|
|
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 important to keep the list of languages up to date in
optinterpreter, otherwise we could have conflicting options when adding
new languages.
|
|
|
|
|