Age | Commit message (Collapse) | Author | Files | Lines |
|
Introspecting non-libtool static libraries requires a gir-scanner fix
which is only in 1.58.1 or later.
|
|
Makes it a bit safer.
|
|
g-ir-scanner works as well with static libraries as with dynamic
|
|
The LLVM toolchain doesn't come with a Windows resource compiler at
the moment. Use 'rc' from the Windows SDK.
|
|
|
|
$ flake8 | grep -E '(E128|E203|E221|E226|E303|W291|W293)'
./mesonbuild/backend/backends.py:32:1: E303 too many blank lines (3)
./mesonbuild/modules/i18n.py:90:56: E128 continuation line under-indented for visual indent
|
|
|
|
When dependency(), find_library(), find_program(), or
python.find_installation() return a not-found object and disabler is
true, they return a Disabler object instead.
|
|
This avoids the problem of generated files with the same name as something in source
existing and using the wrong file.
|
|
It is possible for compiler flags to include special characters, such as
double quotes which are needed to define macros with -D options. Since
gtkdoc-scangobj uses shlex.split to split arguments passed to --cc,
--ld, --cflags, --ldflags into lists, we can safely use shlex.quote to
properly quote arguments for these options.
|
|
|
|
using state.subdir will cause / or \ to be inserted into the target name.
Replace them with @ to future-proof it.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
|
|
|
|
Determine the type of the Windows resource compiler by looking at its output, not its name
|
|
Determine the type of the Windows resource compiler by looking at its
output, not its name.
Also log the name and version of the resource compiler we are using.
|
|
Factor out determination of the windows resource compiler as
_find_resource_compiler(). Cache the result, so the work is only done once.
|
|
When passing static libraries to gtkdoc, they are also appended as
shared libraries to ldflags, which makes the process to fail.
This has been changed to only append shared libraries to ldflags.
Fixes #3935
|
|
|
|
When cross-compiling we shouldn't be passing the native c_args/c_link_args to
g-ir-scanner.
|
|
When cross-compiling the gtk-doc calls were missing the configured c_args and
c_link_args.
|
|
Gtk docs improvements
|
|
If add_project_arguments is used, gtkdoc will ignore it, so make sure we
pick these flags for the compiler too.
Fixes #2901
|
|
|
|
gtk-doc for autotools has the concept of module version, that is used to define
the module install path and the devhelp2 basename.
Add a `module_version` parameter to gnome.gtkdoc to replicate the same behavior.
Updated the test checking that the install_dir is properly computed (if not
passed), and that the .devhelp2 file has proper name.
https://gitlab.gnome.org/GNOME/gtk-doc/blob/GTK_DOC_1_29/buildsystems/autotools/gtk-doc.make#L269
|
|
|
|
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.
|
|
|
|
As it currently stands, if for whatever reason you have two files you
want to merge with the same output name, it will fail due to multiple
targets with the same name due to the target name being autogenerated
from the output kwarg.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
|
|
Closes: #4165.
|
|
Always honour any windres setting in cross-file (we can't be compiling with
msvc, but this should apply when cross-compiling using gcc or clang)
Always honour WINDRES environment variable
Otherwise look for the resource compiler which is part of the same toolset
as the C or C++ compiler.
Add some commentary on why the conventions for compiled resource file
extensions differ between RC and windres
Also don't try to report non-existent path when we couldn't find the
resource compiler.
|
|
|
|
|
|
translations
Previously it wasn't possible to use twice @BASENAME@ as the targets would then be named @BASENAME@_merge
|
|
|
|
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`
|
|
modules: Add an 'hotdoc' module
|
|
Let's eat our own dogfood.
|
|
hotdoc: http://github.com/hotdoc/hotdoc/
|
|
Remove some spurious calls to the format() function, left by mistake after
c2f37853
|
|
Fix compiling multiple Windows resources using pathnames with non-unique basenames
|
|
Use a unique output filename for windows.compile_resources() even when input
basename is not unique.
|
|
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.
|
|
g-ir-scanner barfs on any flags other than -D -I and -U
|
|
Fixes #3688
|
|
The method was getting too long and difficult to make sense
of, this should make maintaining and updating it a bit easier.
|
|
* Lookup is now performed according to the following order:
1. use `pkg-config` with `PKG_CONFIG_LIBDIR=LIBPC` from python
2. use plain `PKG_CONFIG_{LIBDIR,PATH}` from the environment
3. try to extract the information from SYSCONFIG
The second step is necessary for relocated python installations
and cross compilation scenarios, where the value of `LIBPC` might
be wrong.
|
|
scripts/gtkdochelper: add support for --run
|
|
asan must be first in ldflags and this order was lost in cb36add970d448f8b4ace7e4dc6028e5441bccd7
So this is the most simple solution of just putting it first in internal_ldflags
See https://github.com/mesonbuild/meson/issues/2117#issuecomment-408560838
|
|
isn't in PATH
Meson tries to find the interpreter path through the "py" launcher on Windows in all
cases which breaks if meson is run under MSYS2 and an official CPython is installed as well.
MSYS2 Python doesn't install a py launcher which results in meson finding the system one instead
even though python2/python3 is in PATH.
Always check if the interpreter name is in PATH before falling back to checking the py launcher.
|