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.
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
Instead of blindly searching in PATH, use
Qt5Dependency.compilers_detect() (same for qt4) to get moc/uic/rcc.
This is much more robust, and it improves the chances that the correct
ones will be found. We still manually verify for now because the
fallback in dependencies.py for searching is stll to look in PATH for
backwards-compat, and because people probably have setups like that.
Also sync the qt4 module with the qt5 module w.r.t. resource compilation
and make the compiled qrc.cpp file unique in terms of the framework
version used (4 vs 5). This is needed for the test to work properly,
which now covers both Qt4 and 5.
Without this a strange exception is spewed that no one would be able to
understand. Finding each of those compilers isn't a problem unless
sources are specified that require those compilers, so only error out in
those cases.
Closes#758