For now dicts are immutable, and do not expose any methods,
they however support "native" syntax such as [] lookup,
and foreach iterating, and can be printed.
The fallback might be not used not only because it couldn't be found, but
also because something went wrong trying to use it.
Also, update a test which relies on the specific text
To allow the javac -implicit:class behaviour to know where to find
generated .java files then the build directory for the target is also
added to the -sourcefile path.
Although only one file is passed to javac at a time, if your code has
any inter-file dependencies javac still needs to know how to find other
source files for its -implicit:class feature to work whereby it will
automatically also compile files that the given file depends on.
-implicit:class is the default, practical, behaviour of javac since
otherwise it would be necessary to declare the class dependencies
for parallel java builds to be feasible.
Passing "include_directory: include_directory('.')" to jar() causes
-souredir <path/to/top/of/java/src> to be passed to javac which then
enables your source code to have inter-file class dependencies -
assuming none of your source code is generated.
This ensures that '.' is included by default.
The -sourcepath option can't be passed multiple times to javac, since it
simply overrides prior arguments. Instead -sourcepath takes a colon (or
semi-colon on windows) separated list of paths.
It seems that some projects relied on the previously buggy
behaviour of accepting a 2-element list as the single argument
to configuration_data.set().
Special-case this behaviour, and emit a deprecation message.
We were setting it to a file list that would always be wrong, and
always out of date since it would never exist.
However, the output list is not predictable. It usually has a 1-1
relationship with the input XML files, but it may not.
This must be fixed later with API for users to provide the output
names.
See: https://github.com/mesonbuild/meson/pull/3539
If we pass a source files() object, we will look for it in the build
directory, which is wrong. If we pass a build files() object (from
configure_file()), we will find it in the build directory, and then
try to copy it on top of itself in gtkdochelper.py getting a
SameFileError.
Add a test for it, and also properly iterate custom target outputs
when adding to content files.
The fix has landed upstream, and will be in the next glib stable
release. I have verified that it fixes the problem described in #3488
and that the 'frameworks/7 gnome' test passes now.
The new --body and --header args are broken because they do not allow
the use of --output-directory to set the correct `#include "foo.h"`
line in `foo.c`. The changes in the gdbus test case show this.
Disabled till this can be fixed in glib.
Closes https://github.com/mesonbuild/meson/issues/3488
pypy installations don't usuallyy ship with pkg-config files,
we thus need to replicate what their version of distutils does.
In addition, we also try our best to build against other
pythons that do not have pkg-config files.
Libraries that have been linked with link_whole: are internal
implementation details and should never be exposed to the outside
world in either Libs: or Libs.private:
Closes https://github.com/mesonbuild/meson/issues/3509
This change still relies on the older 'ANSICON' environment check as a
fallback, in the event we're on "not Windows 10". (Calling
`SetConsoleMode` with unsupported values results in a 0 being returned)
When passing more than one -Dc_args it should override the value
instead of appending. This is how all other options works.
Value should be split on spaces using shlex just like it does with
CFLAGS environment variable.
Fixes#3473.
Outputs two profile logs: one for the interpreter run and another for
the backend-specific build file generation. Both are stored in
meson-private in the build directory.
What is actually defined here varies wildly on different python-versions
for different platforms.
On my python2.7 on Windows len(sysconfig.get_config_vars()) returns 17,
whereas in my Ubuntu that number is 517!
Hence it is useful to be able to check which keys are available, as
well as allowing specifying a default option.
* gnome: If pkg-config is not found, assume glib is 2.0
Checking the pkg-config file to confirm tool versions is a hack, and
should eventually be replaced with checking the actual versions of the
tools.
* gnome: Actually assume glib version is 2.54 if not found
It is actually not possible to build most projects with the GNOME
module if your glib is older, particularly genmarshal and
gdbus-codegen generate unusable output without newer arguments that
were added for Meson.
Mathieu Duponchelle
Kyrylo Shpytsya
Ryan Gonzalez
Jon Turney
Robert Bragg
Nirbheek Chauhan
Jasper Lievisse Adriaanse
Jussi Pakkanen
David Seifert
Isabella Muerte
Xavier Claessens
Niklas Claesson
Martin Hostettler
Filipe Brandenburger
Havard Graff
Nirbheek Chauhan