gtkdoc-scangobj also accepts compiler arguments. In the same way
that include_directories includes directories, the new c_args
parameter also appends compiler arguments.
One of the gtkdoc's steps calls to gtkdoc-scangobj that also accepts
compiler arguments by using the cflags option.
Compiler arguments from dependencies are also appended now.
The regression was introduced in my recent refactoring of
that method (8377ea4).
This commit simply restores the ordering of the generated
scan_command, ensuring `-lasan` and other internal linker
flags come before `--library` or `--program`
g-ir-scanner is very picky about the flags that it can accept, so the
build fails on macOS if you have Framework external dependencies,
which add -F and -framework arguments.
Also fix incorrect de-duping of -framework arguments for gtkdoc.
* Fix flake8 whitespace reports
$ flake8 | grep -E '(E203|E221|E226|E303|W291|W293)'
./mesonbuild/coredata.py:337:5: E303 too many blank lines (2)
* Fix flake8 'variable assigned value but unused' reports
$ flake8 | grep -E F841
./mesonbuild/modules/gnome.py:922:9: F841 local variable 'target_name' is assigned to but never used
* Fix flake8 'imported but unused' reports
$ flake8 | grep F401
./mesonbuild/compilers/__init__.py:128:1: F401 '.c.ArmclangCCompiler' imported but unused
./mesonbuild/compilers/__init__.py:138:1: F401 '.cpp.ArmclangCPPCompiler' imported but unused
./mesonbuild/modules/__init__.py:4:1: F401 '..mlog' imported but unused
PR #3717 imports ARMCLANG compilers in __init__, but does not add them to
__all__, so they are not re-exported by the compilers package like
everything else.
* More details about flake8 in Contributing.md
Mention that Sider runs flake8
Suggest seting flake8 as a pre-commit hook
Those tools use our arguments to build a file and execute it to
introspect it at runtime. However, they do not know that you can pass
the full path to the library to use, and ignore the arguments.
The long-term fix for this is to have them output a .c file that Meson
will build for them, which they can then run, but that will require
upstream changes:
https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/1
Closes https://github.com/mesonbuild/meson/issues/3774
When an older version of the library being built is installed in the
same prefix as external dependencies, we have to be careful to construct
the linker or compiler command line. If a -L flag from external
dependencoes comes before a -L flag pointing to builddir, it is possible
for the linker to load older libraries from the installation prefix
instead of the newly built ones, which is likely to cause undefined
reference error.
Since the order of dependencies is not significant, we cannot expect
internal dependencies to appear before external dependencies when
recursively iterating the list of dependencies. To make it harder to
make mistakes, linker flags come from internal and external
dependencies are now stored in different order sets. Code using
_get_dependencies_flags are expected to follow the order when
constructing linker command line:
1. Internal linker flags
2. LDFLAGS set by users
3. External linker flags
It is similar to what automake and libtool do for autotools projects.
In GLib when running "ninja gio-doc" without doing a full build first,
it won't build libraries and the generated gio-scan.c gets linked
against system libgio instead.
This fix 2 bugs: gtkdoc() was not passing 'depends' variable down to
_get_dependencies_flags(), and many places had 'if depends' which is
False when 'depends' is an empty list and not only when it's None. There
is no reason for that argument to be optional, we always want to collect
dependencies.
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
* 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.
The `install` parameter that is present in the `permittedKwargs`
annotation is wrong. The correct parameter name, which is also
consistent with the rest of functions in the `gnome` module, is
`install_dir`.
The `ct` variable used in the ModuleReturnValue is created only for
versions earlier than 2.55.2. However, in newer versions that
variable does not exist.
The development version of `glib` (2.55.2) has acquired support for
generating gdbus header and source code files separately. This
allows dependencies to be more fine grained on those targets
depending only on the header.
* Never install the glib-mkenums generated C source
When using gnome.mkenums_simple() we end up installing the generated
C source file alongside the C header file, if `install_header` is set
to True. This is caused by mkenums_simple() acting as a wrapper for
mkenums() without template files; mkenums() won't be able to know if
we're generating the header or the source, and will use the presence
of `install_header` as the deciding factor as to whether the generated
file should be installed.
When generating the C source file, we should always unset the
`install_header` option to False, just like mkenums() expects.
Closes#3373
* Verify that mkenums_simple() does not install C sources
When asked to installed the generated C header file.
The reason for this change is the same as the previous commit. Although
g-ir-scanner can pick arguments from CFLAGS, CPPFLAGS, LDFLAGS
environment variables by itself, it is still better for build systems
to put them on the command line instead of relying on users to setup
the same environment.
Since g-ir-scanner doesn't provide a way to set arbitrary linker flags
on the command line, arguments in LDFLAGS that are not started with -L
are not passed.
GLib-based libraries and applications require gettext library to compile
and link. On non-GNU systems such as FreeBSD, gettext is not included in
libc and it is required to pass '-L/usr/local/lib -lintl' to the linker
to satisfy the dependency on gettext. The pkg-config file provided by
GLib already has '-lintl', but users still have to remember to put
'-L/usr/local/lib' into LDFLAGS. If we don't pass LDFLAGS to
gtkdoc-scangobj, the linker will not be able to find '-lintl' when no
dependencies of the project provides '-L/usr/local/lib'.
Since all *FLAGS are commonly used in many build systems, this commit
adds support for not only LDFLAGS but also CFLAGS and CPPFLAGS.
Fixes#1724
The gtkdoc function can also use generated targets to create
documentation. However, the dependencies over these generated files
are missing, so these must be also included in the run target.
gnome's gtkdoc function does not support content files which are
not strings. However, there are situations where files generated
by other targets might be needed.
* mesonbuild/modules/gnome.py (GnomeModule.compile_schemas): Allow the
depend_files kwarg.
* docs/markdown/Gnome-module.md: Add docs for new kwarg (and the only
other one that is permitted).
Currently, run_target does not get namespaced for each subproject,
unlike executable and others. This means that two subprojects sharing
the same run_target name cause meson to crash.
Fix this by moving the subproject namespacing logic from the BuildTarget
class to the Target class.
This allows a CustomTarget to be indexed, and the resulting indexed
value (a CustomTargetIndex type), to be used as a source in other
targets. This will confer a dependency on the original target, but only
inserts the source file returning by index the original target's
outputs. This can allow a CustomTarget that creates both a header and a
code file to have it's outputs split, for example.
Fixes#1470
This also adds a "# noqa: F401" comment on an unused "import lzma",
which we are using it in a try/except block that is being used to
check if the lzma module is importable; of course it is unused.
v2: This turned out to be a little tricky.
mesonbuild/modules/__init__.py had the "unused" import:
from ..interpreterbase import permittedKwargs, noKwargs
However, that meant that the various modules could do things like:
from . import noKwargs # "." is "mesonbuild.modules"
Which breaks when you remove __init__.py's "unused" import. I
could have tagged that import with "# noqa: F401", but instead I
chose to have each of the module import directly from
"..interpreterbase" instead of ".".
Add new 'docbook' argument which generates Docbook documentation for
each D-Bus interface. The docbook argument will be used as prefix
in `PREFIX`-NAME.xml pattern, and NAME will be replaced by the D-Bus
interfaces.
If we don't do that, the traversal of the sources list to generate the
sources file for g-ir-scanner is going to explode with a Python
backtrace like this one:
File "/usr/lib/python3.5/site-packages/mesonbuild/modules/gnome.py", line 463, in generate_gir
gir_filelist.write(os.path.join(srcdir, s) + '\n')
File "/usr/lib/python3.5/posixpath.py", line 89, in join
genericpath._check_arg_types('join', a, *p)
File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types
(funcname, s.__class__.__name__)) from None
if the sources list contains a list.
On Windows, one will face the issue of the 8192-character limit for each
command line, so this will cause an issue when one is building items
like GTK+ with introspection, because the g-ir-scanner command line will
likely get too long, which will clearly break the build. This will
affect all Windows builds.
Make use of the --filelist option that is already in g-ir-scanner, and
generate such a file list from the sources that are fed to
generate_gir(), named as
$(builddir)/$(target_id)/<NameSpace>_<NameSpaceVersion>_gir_filelist
and using it during the build.
99% of all mkenums uses in C libraries use the same basic template,
so add a mkenums_simple() function that takes care of everything for
us based on that template.
Features:
- optional function declaration decorator such as GLIB_AVAILABLE
- optional extra header prefix (e.g. for include needed for decorator)
- optional extra body prefix (e.g. for additional includes)
- optional function name prefix (e.g. to add leading underscores)
Fixes issue #1384
gnome.compile_resources() was not parsing custom target sources
properly. It was using the custom target name as the output of the
custom target instead of looking at the list of outputs.
Also modify the GNOME framework test to expose this.
We prefer to use the --extra-library parameter for passing -l arguments
to g-ir-scanner, however we need to be careful to only replace the first
'-l' occurrence to not translate
'-lfoo-lib'
to
'--extra-library=foo--extra-library=ib'
The glib-genmarshal tool was rewritten in GLib 2.53.3, and now supports
more command line arguments, such as:
"--pragma-once": emits a "#pragma once" instead of the old header
guards when generating the header file
"--prototypes": emits the marshallers prototype when generating the
source file
"-D,-U": defines and undefines pre-processor symbols
"--include-header": emits an "#include" directive when generating the
source file for the specified header file
Meson should take advantage of these new options, as they can be used to
replace most of the ad hoc build rules that projects are currently using
to implement the same thing.
Instead of mapping each option to a named argument, I used the same
approach as the compile_resources() and generate_gir() methods; the
genmarshal() method now has an 'extra_args' argument that can be used to
pass extra arguments to the glib-genmarshal tool.
When dealing with the SharedLibrary or StaticLibrary include
directories, we where not taking into acount that path are relative to
the source tree. With proper helper, this works now. This fixues issue
where the gir may be generated bug from headers found in the prefix.
While g-ir-scanner's compatible -I and -D flags cover what most dependencies
use, there's no guarantee that a dependency's cflags don't include more
exotic flags that conflict with the tool's own options.
For a real world example, mozjs-38 has '-include some-header-file.h', which
translates to '--include nclude another-file-to-scan.h' for the scanner;
unless for some reason there's an 'nclude' GIR available on the system,
the target will thus fail.
For this purpose, g-ir-scanner allows explicitly marking some flags as
preprocessor/compiler flags by guarding them with --cflags-begin and
--cflags-end. Make sure it is used this for all cflags, not only for
global and project flags.
This class now consolidates a lot of the logic that each external
dependency was duplicating in its class definition.
All external dependencies now set:
* self.version
* self.compile_args and self.link_args
* self.is_found (if found)
* self.sources
* etc
And the abstract ExternalDependency class defines the methods that
will fetch those properties. Some classes still override that for
various reasons, but those should also be migrated to properties as
far as possible.
Next step is to consolidate and standardize the way in which we call
'configuration binaries' such as sdl2-config, llvm-config, pkg-config,
etc. Currently each class has to duplicate code involved with that
even though the format is very similar.
Currently only pkg-config supports multiple version requirements, and
some classes don't even properly check the version requirement. That
will also become easier now.
There are cases where we need to specify arguments to gtkdoc-mkdb, like
telling it to scan extensions that are not '.h' and '.c'. Let's add a
new named argument to gnome.gtkdoc(), as well as the plumbing needed for
the gtk-doc helper script.
Meson has a common pattern of using 'if len(foo) == 0:' or
'if len(foo) != 0:', however, this is a common anti-pattern in python.
Instead tests for emptiness/non-emptiness should be done with a simple
'if foo:' or 'if not foo:'
Consider the following:
>>> import timeit
>>> timeit.timeit('if len([]) == 0: pass')
0.10730923599840025
>>> timeit.timeit('if not []: pass')
0.030033907998586074
>>> timeit.timeit('if len(['a', 'b', 'c', 'd']) == 0: pass')
0.1154778649979562
>>> timeit.timeit("if not ['a', 'b', 'c', 'd']: pass")
0.08259823200205574
>>> timeit.timeit('if len("") == 0: pass')
0.089759664999292
>>> timeit.timeit('if not "": pass')
0.02340641999762738
>>> timeit.timeit('if len("foo") == 0: pass')
0.08848102600313723
>>> timeit.timeit('if not "foo": pass')
0.04032287199879647
And for the one additional case of 'if len(foo.strip()) == 0', which can
be replaced with 'if not foo.isspace()'
>>> timeit.timeit('if len(" ".strip()) == 0: pass')
0.15294511600222904
>>> timeit.timeit('if " ".isspace(): pass')
0.09413968399894657
>>> timeit.timeit('if len(" abc".strip()) == 0: pass')
0.2023209120015963
>>> timeit.timeit('if " abc".isspace(): pass')
0.09571301700270851
In other words, it's always a win to not use len(), when you don't
actually want to check the length.
You can now pass a list of strings to the install_dir: kwarg to
build_target and custom_target.
Custom Targets:
===============
Allows you to specify the installation directory for each
corresponding output. For example:
custom_target('different-install-dirs',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : ['somedir', 'otherdir])
This would install first.file to somedir and second.file to otherdir.
If only one install_dir is provided, all outputs are installed there
(same behaviour as before).
To only install some outputs, pass `false` for the outputs that you
don't want installed. For example:
custom_target('only-install-second',
output : ['first.file', 'second.file'],
...
install : true,
install_dir : [false, 'otherdir])
This would install second.file to otherdir and not install first.file.
Build Targets:
==============
With build_target() (which includes executable(), library(), etc),
usually there is only one primary output. However some types of
targets have multiple outputs.
For example, while generating Vala libraries, valac also generates
a header and a .vapi file both of which often need to be installed.
This allows you to specify installation directories for those too.
# This will only install the library (same as before)
shared_library('somevalalib', 'somesource.vala',
...
install : true)
# This will install the library, the header, and the vapi into the
# respective directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : ['libdir', 'incdir', 'vapidir'])
# This will install the library into the default libdir and
# everything else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [true, 'incdir', 'vapidir'])
# This will NOT install the library, and will install everything
# else into the specified directories
shared_library('somevalalib', 'somesource.vala',
...
install : true,
install_dir : [false, 'incdir', 'vapidir'])
true/false can also be used for secondary outputs in the same way.
Valac can also generate a GIR file for libraries when the `vala_gir:`
keyword argument is passed to library(). In that case, `install_dir:`
must be given a list with four elements, one for each output.
Includes tests for all these.
Closes https://github.com/mesonbuild/meson/issues/705
Closes https://github.com/mesonbuild/meson/issues/891
Closes https://github.com/mesonbuild/meson/issues/892
Closes https://github.com/mesonbuild/meson/issues/1178
Closes https://github.com/mesonbuild/meson/issues/1193
This avoids unnecessary rebuilds occuring when Meson regenerates the
build.ninja file. Previously, if the ordering of the commandline
arguments changed then Ninja would consider the outputs dirty and
rebuild them.
There is no need to do obj.get_command() and in fact it's wrong
because the VS backends need to resolve each object to absolute paths
and get_command() does not do that.
This should fix invocation of GNOME module helpers with the VS backends
For the record, absolute paths for programs are needed because the
same PATH environment won't necessarily be available to Visual Studio
when it builds the generated solution.
Related to https://github.com/mesonbuild/meson/issues/1419
This used to produce a warning, but then would crash anyway. It's
simpler if we just error out and have the user disable gir generation or
install gobject-introspection.
We can't support generated XML files with custom_target() because the
dependency scanning happens at configure time, but we *can* support
generating them with configure_file().
Closes https://github.com/mesonbuild/meson/issues/1380
We don't need dependencies to work correctly to use the output of
configure_file in the dependencies: kwarg.
This allows GNOME Recipes to built without the latest glib git.
Iñigo Martínez