It's a method on the QtDependeny that exists purely for the consumption
of the qt module (in the form, return some stuff the module makes into
an instance variable). So put it where it actually belongs, and pass the
qt dependency into it.
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
A common pattern in Qt5 applications is to embed translations in the
executable using the qresource system. In this case, the list of
translation files is already available in the .qrc file and there's no
good reason to duplicate this info in meson.build.
Let compile_translations optionally take a qrc input, in which case it
will go straight to generating the relevant translations and
rcc-generated .cpp, and directly return the thing users actually care
about -- the .cpp for linking.
Add depfile support to generated targets for Qt >= 5.14.
Move warning into the module init itself, to check if the version is too
old before issuing. Also tweak the wording itself, to advise upgrading
to a suitable version of Qt5 instead of advising to wait for a Qt bug to
be fixed.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
This makes the typing annotations basically impossible to get right, but
if we only have one key then it's easy. Fortunately python provides
comprehensions, so we don't even need the ability to pass multiple keys,
we can just [extract_as_list(kwargs, c) for c in ('a', 'b', 'c')] and
get the same result.
When lrelease-qtN is missing, upgrade the error message from the
cryptic:
meson.build:75:4: ERROR: Tried to use not-found external program in "command"
to the meaningful:
meson.build:75:4: ERROR: qt.compile_translations: lrelease-qt5 not found
Issue found and tested with "test cases/frameworks/4 qt/"
Too few arguments for string format. Format "{0} sources specified and
couldn't find {1}, please check your qt{2} installation" requires at least
3, but 2 are provided.
This alert was introduced in f7f439c a year ago
Since relative path in qrc files are always relative to qrc file
itself then we just need to check that normpath(qrc file + resource)
doesn't start with build dir path, this would mean that the resource is
generated.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
When several qrc files are given all qrc files dependencies were mixed.
Fixed non working use case:
When user try to guess build dir layout and add use a relative
path between a generated qrc file and a generated resource.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
In order to handle generated resources embedded in qrc file, we
need to be able to detect if files pointed from qrc are in build
directory or not.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
Adding the current subdir when extracting resources deps wasn't good,
it is CustomTarget job to handle that.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Depending on the tool (moc, uic, rcc, lrelease), the Qt version
(4.8, 5.7, 5.9) and the distribution (Fedora, debian,...) it seems you
cannot predict which of -v or -version will be supported.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
- Added a new compile_translations method since preprocess was already quite
full and translations compilation is quite different from ui, qrc, cpp files
preprocessing.
- Updated translation.
- Updated test case.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
Just detect lrelease as done with other Qt tools.
Uses -version instead of -v to probe version since lrelease don't
support it.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
- removed a typo in tools detection loop
- added include dir also when parsing cpp sources with moc, not only headers
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This patch sets the --name option for files processed with
rcc. It generates an additional initialization function,
which can be used with static linking.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
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 commit adds support for an additional `moc_extra_arguments` keyword.
It becomes especially handy, when `moc`-ed sources conditionally provide
`slots`, depending on compile time macros (i.e. defines).
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 ".".
configure a detection method, for those types of dependencies that have
more than one means of detection.
The default detection methods are unchanged if 'method' is not
specified, and all dependencies support the method 'auto', which is the
same as not specifying a method.
The dependencies which do support multiple detection methods
additionally support other values, depending on the dependency.