| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It was generating #include with the basename of every header file. That
assumes that every directory where there are headers are also included
into search path when compiling the .c file.
Change to use path relative to current subdir, which can be both in
build or source directory. That means that we assume that when the .c
file is compiled, the target has a include_directories pointing to the
directory where gnome.mkenum_simple() has been called, which is
generally '.' and added automatically.
Also fix type annotation to only allow str and File sources, other types
have never been working, it would require to iterate over custom target
outputs, etc.
Fixes: #7582
|
|
|
|
Allow macro_name to be speficied as a parameter to configure_file().
This allows C macro-style include guards to be added to
configure_file()'s output when a template file is not given. This change
simplifies the creation of configure files that define macros with
dynamic names and want the C-style include guards.
|
|
|
|
- On Windows, it was not detected if include directory was an absolute
path to source directory, because of the mis of path separators.
- In the edgecase the include directory begins with the exact same
string as the source directory, but is a different directory, it was
falsely reported as an error.
Fixes #12217.
|
|
Installing python sources causes the python module to call
create_install_data() before Ninja backends adds extra outputs to Vala
targets.
Target objects are supposed to be immutable, adding outputs that late is
totally wrong. Add extra vala outputs immediately, but be careful
because the main output is only added later in post_init(). Luckily
the base class already puts a placeholder item in self.outputs for the
main filename so we can just replace self.outputs[0] instead of
replacing the whole list which would contain vala outputs at that stage.
This is surprisingly what SharedLibrary was already doing.
|
|
Fixes: #12202
|
|
Adds a new method to the compiler object, has_define.
This makes it possible to check if a preprocessor macro/define
is set or not.
This is especially helpful if the define in question is empty,
for example:
#define MESON_EMPTY_DEFINE
This would yield the same results as a missing define with
the existing get_define method, as it would return an empty
string for both cases. Therefore this additional method is
needed.
|
|
This forces the use of the Apple archiver, since that archiver doesn't
add extern'd variables to the symbol table automatically, and instead
requires that ranlib be used. A native file is used to ensure that
Apple's ar is used even in the presence of llvm or gcc in the path with
their superior archivers.
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
|
|
Fixes #12182
|
|
Allow packagecache to contain already extracted directory to match what
some distro does with Cargo source packages in /usr/share/cargo/registry.
Note that there is no need to lock the cache directory because we
download into a temporary name and atomically rename afterward. It means
we could be downloading the same file twice, but at least integrity is
guaranteed.
Fixes: #12211
|
|
|
|
The bug it was blocked on was fixed in
a0514a7c4183a9e42d436865087d2f887d658d54.
|
|
See https://gitlab.kitware.com/cmake/cmake/-/issues/25200.
|
|
|
|
c_std, cpp_std: Change to a list of desired versions in preference order
|
|
gtkdoc() and generate_gir() methods assumes there is a C compiler, but
pure C++ projects might not add it explicitly.
Fixes: #12162
|
|
Compiler checks were not adding build dir side, which prevents using
headers generated with configure_file().
|
|
Fixes: #11797
|
|
The include directories were not passed to the compiler.
|
|
This reverts commit 84c8905d527893bedc673e8a036b8b2ec89368b4.
Fixed the cygwin failure...
|
|
This reverts commit f52bcaa27fc125ab9ae583af466ba99c164169f3.
It did not pass CI, and was merged anyway because there were two CI
errors in the same cygwin job. The other error was not the fault of this
commit, and since cygwin errors were glossed over because they were
"expected", the presence of a new error *added* by this commit was
overlooked.
Per the meson development policy, PRs which result in CI errors
can/should be reverted at will, no questions asked.
|
|
|
|
|
|
This was an unintended consequence of the original patch in #11977.
Co-authored-by: Benoit Pierre <benoit.pierre@gmail.com>
|
|
Returns a relative path from arg 2 to arg 1 similar to
os.path.relpath().
|
|
|
|
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
|
|
Since CPython 3.8 .pyd files no longer look in PATH for loading libraries,
but require the DLL directory to be explicitely added via os.add_dll_directory().
This resulted in those tests failing with 3.8+ on Windows.
Add the DLL build directory with os.add_dll_directory() to fix them.
This was never noticed in CI because it only uses Python 3.7 and the
MSYS2 CPython still used the old behaviour until now.
|
|
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
|
|
Projects that prefer GNU C but can fallback to ISO C can now set for
example `default_options: 'c_std=gnu11,c11'` and it will use gnu11 when
available, fallback to c11 otherwise. It is an error only if none of the
values are supported by the current compiler.
This allows to deprecate gnuXX values from MSVC compiler, that means
that `default_options: 'c_std=gnu11'` will now print warning with MSVC
but still fallback to 'c11' value. No warning is printed if at least one
of the values is valid, i.e. `default_options: 'c_std=gnu11,c11'`.
In the future that deprecation warning will become an hard error because
`c_std=gnu11` should mean GNU is required, for projects that cannot be
built with MSVC for example.
|
|
Fixes: #5399
|
|
add the "required" keyword to the functions
has_function
has_type
has_member
has_members
has_argument
has_multi_arguments
has_link_argument
has_multi_link_argument
has_function_attribute
Co-authored-by: Milan Hauth <milahu@gmail.com>
|
|
|
|
Share a common function to convert objects to display strings for
consistency.
While at it, also add support for formatting user options.
|
|
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a31981874310a78dde0df59a6a7c5ebb29 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
|
|
This fixes two issues in constructing the default installation path
when install_dir is not specified:
- inside a subproject, install_data() would construct the destination
path using the parent project name instead than the current project
name,
- when specifying preserve_path, install_data() would construct the
destination path omitting the project name.
Fixes #11910.
|
|
When the pkgconfig module is imported, but not used, it will insert None
on the end of the devenv list. This list is not expected to contain
None, and causes Meson to crash. This can happen in complex build setups
(reported from mesa), where pkgconfig is only used in some
configurations
Fixes: #12032
|
|
the previous version didn't even link to libhdf5_cpp.so
|
|
Based on https://opensource.google/documentation/policies/cplusplus-support
Google no longer supports C++11, and protobuf spawns an `#error` if you
don't have at least 14.
So, perform our currently scheduled automatic bump.
|
|
It has been rebuilt to no longer provide the deprecated gpgme-config
tool.
|
|
It fails with glib >= 2.76 and gobject-introspection <= 1.76.1.
Fixes: #11754
|
|
Do not run tests that use integers in versions with compiler that do
not support them.
Old versions of GDC supported plain integers in version and debug
strings but they are deprecated and GDC 13 hard errors on them.
|
|
These result in very large binaries when linked, and are not generally
useful. A user can turn them back on by passing `-C overflow-checks=yes`
manually via `-Drust_args` or the `RUSTFLAGS` environment variable
fixes: #11785
|
|
In order to pass a File object down into the compiler impl and compile
it, we cannot pass a string with the filename, and we cannot either pass
the File object as-is, since it relies on being given Environment
attributes to calculate the relative location. So we build a fresh File
object as an absolute path.
But the code to do this was totally broken. Instead of using the File
method to get an absolute path, we used one that expected to create
builddir-relative paths... and then gave it the absolute source dir as
the "relative path portion" prefix. This worked by accident as long as
it wasn't a built File, but if it was a built file then we intentionally
didn't include that prefix -- which was wrong anyway, since we need the
build directory!
Use the correct method to get an absolute path in all cases, and emit a
warning if it was a built file. This never worked. Sometimes it crashed,
sometimes it silently returned false.
Fixes #11983
|
|
On windows, meson would mix posix and windows dir separators in the
computed PACKAGE_RELATIVE_PATH.
Here we force posix directory separator even on Windows. This matches
the CMake behavior and fixes interpretation of the resulting path.
Fixes #6955
Fixes #9702
|
|
By specifiying explicit encodings, we can silence warnings like:
/__w/meson/meson/test cases/common/100 postconf with args/postconf.py:15: EncodingWarning: 'encoding' argument not specified
with open(input_file) as f:
in CI.
|
|
Replace unencodable XML chars with their printable representation, so
that, xmllint can parse test outputs without error.
Closes #9894
Co-authored-by: Tristan Partin <tristan@partin.io>
|
|
This fixes regression caused by
https://github.com/mesonbuild/meson/commit/3162b901cab46d66a30c66a4406195523714ecdc
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
|
|
When a link() is promoted to link_whole() we still have to handle the
rest of the list.
Fixes: #11956
|
