Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
If the feature hadn't been broken in the first place it would have
worked on them anyway, so we might as well expose it. I'm loathe to do
it because one of the best features of meson in a mixed C/C++ code base
is that meson figures out the right linker every time, but there are
cases people have where they want to force a linker. We'll let them keep
the pieces.
This adds support for Files, CustomTarget, Indexs of CustomTargets,
ConfigureFiles, ExternalPrograms, and Executables.
Fixes: #1234Fixes: #3552Fixes: #6175
- ExternalProgramHolder has path() method while CustomTargetHolder and
BuildTargetHolder have full_path().
- The returned ExternalProgramHolder's path() method was broken, because
build.Executable object has no get_path() method, it needs the
backend.
- find_program('overridden_prog', version : '>=1.0') was broken because
it needs to execute the exe that is not yet built. Now assume the
program has the (sub)project version.
- If the version check fails, interpreter uses
ExternalProgramHolder.get_name() for the error message but
build.Executable does not implement get_name() method.
By building the generator for the build machine always, and only for the
host machine if an exe_wrapper is available. This makes sense to me as
generally you are going to build the generator for the build machine,
not the host machine, but testing on the host machine makes sense too.
The arithmetic operators are now split into two groups:
* The add/sub group: +, -
* The mul/div group: *, /, %
All operators within the same group are left-associative and have equal
precedence. The mul/div group has a higher precedence than the add/sub
group, as one would expect.
Previously every operator had a different precedence and was
right-associative, which resulted in surprising behavior.
This is a potentially breaking change for projects that relied on the
old incorrect behavior.
Fixes#6870
This make relative pathes shorter an too give a chance to
de-duplicate -isystem flags just like -I flags.
Fix common test case 203 for OSX build host too
The previous code was assuming that options do not depend on each
other, and that you can set defaults using `dict.setdefault()`. This
is not true for `buildtype` + `optimization`/`debug`, so we add
defaults + overrides in the right order and use the options parsing
code later to compute the values.
Includes a test.
Closes https://github.com/mesonbuild/meson/issues/6752
Similar to meson.override_find_program() but overrides the result of the
dependency() function.
Also ensure that dependency() always returns the same result when
looking for the same dependency, this fixes cases where parts of the
project could be using a system library and other parts use the library
provided by a subproject.
As any child of BuildTargetHolder might need the name of the object,
provides a method to get object name.
This is useful in gst-build to display the plugin name and not
the filename.
Running the build step of test '127 custom target directory install'
again, using the VS backend, causes 'docgen.py' to try to create the
target directory again (which fails with a FileNotFound exception).
I'm guessing that perhaps this is a shortcoming of the VS backend that
it doesn't correctly give this target a dependency on the directory.
I'm not sure that this test is actually valid meson: the reference
manual says custom_target(output:) should be a list of files, and not a
directory, as is this case here.
Test that the host_machine is correctly detected after add_languages(),
when no langauge is initially specified in project().
In the MSYS2 MSYSTEM=MINGW32 environment (64-bit MSYS2 but with a
i686-w64-mingw32 targeted gcc as gcc) this test fails, as it
(incorrectly) tries to build retval-x86_64.S using an x86 compiler.
On Windows, the basename is used to determine the name of the PDB
file. So for a project called myproject, we will create myproject.dll
and myproject.exe, both of which will have myproject.pdb. This is
a file collision. Instead, append `_test`, similar to the C# template.
Fixes AllPlatformTest.test_templates on MSVC. This became a hard error
when we started listing PDBs in the implicit outputs list of ninja
targets.
Do the same for a test that was making the same mistake.
This allows users to disable writing out the inbuilt variables to
the pkg-config file as they might actualy not be required.
One reason to have this is for architecture-independent pkg-config
files in projects which also have architecture-dependent outputs.
For example : https://gitlab.freedesktop.org/wayland/weston/issues/269Fixes#4011
Looking at 45c8557d, the idea behind this seems to be that a test could
conditionally indicate that the list of installed files should not be
validated by creating that file.
It's no longer used anywhere.
Also remove a lingering no-install-files file which isn't used since commit
c693bd9b.
Currently it's just like if all builtin/base/compiler options are
yielding. This patch makes possible to have non-yielding builtin
options. The value in is overriden in this order:
- Value from parent project
- Value from subproject's default_options if set
- Value from subproject() default_options if set
- Value from command line if set
With GCC 10, -fno-common becomes default behavior, meaning that any
subtly-broken code will be broken not so subtly anymore.
This commit changes the linkage to variables declared in headers to
external and, where needed, adds additional definitions in other
compilation units.
* xenial doesn't ship many dependencies, so make them all optional
since we don't guarantee that everything will work
* cmake/{5,6}: needs stdlib.h for EXIT_SUCCESS on GCC 5
* common/222: needs C++11, and GCC 5 doesn't understand `auto`
correctly unless we explicitly enable it.
* frameworks/1 boost: xenial doesn't ship boost_python3, so make it
properly optional
* frameworks/6 gettext: gettext can be installed without xgettext,
which doesn't cause the project to fail, but the installed files
list is different which causes the test to fail.
* frameworks/7 gnome: gobject-introspection can't be enabled because
the sanitizer unit test detects leaks in glib and fails
declare_dependencies
This allows dependencies declared in subprojects to set variables, and
for those variables to be accessed via the get_variable method, just
like those from pkg-config and cmake. This makes it easier to use
projects from subprojects in a polymorphic manner, lowering the
distinction between a subproject and an external dependency every
further.
Paolo Bonzini
James Hilliard
Dylan Baker
Xavier Claessens
Daniel Mensinger
Marc-André Lureau
Jon Turney
Jussi Pakkanen
Andrei Alexeyev
ClausKlein
Nirbheek Chauhan
Stéphane Cerveau
Rohan Garg
Michael Hirsch, Ph.D
Michael Hirsch, Ph.D
Ernestas Kulik
Sebastien Bacher