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.
* Simpler picking of pkg-config vs qmake detection
* qmake-based detection now allows specifying qmake via cross-info
* bindir is now stored from qmake/pkg-config detection and can be used
to detect qt tools such as moc, uic, rcc with self.compilers_detect()
* Qt4 dependencies got some love; now they share the implementation with
Qt5 since the two are very similar; basically identical
* Don't ask about Qt3
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
With MSVC 2013 and newer, using pre-compiled headers with .pdb debugging
fails with the following error message:
fatal error C1041: cannot open program database '[...]\prog.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
So we use /FS when PCH is enabled. When PCH is enabled and debugging is
disabled, this will have no effect since .pdb files will not be written.
Previously we were just dumping all defines and include directories into
the target-wide list of defines and include directories. Now we have
separate per-target and per-file (actually per-language) arguments,
defines, and include directories.
- Use depfile support on recent glib-compile-resources
- Don't pass dep files to header ever
- Pass depends for generated deps
- Avoid duplicate --sourcedir args
- Include correct subdir of generated deps
We already pass everything else (custom targets, build targets, etc) as
absolute paths, and this is the only sane way to handle this till we
rework the codebase to use File objects everywhere (after reworking the
File object itself).
Fixes https://github.com/mesonbuild/meson/issues/957
Without this, we error out with an exception if `javac` is found but
`java` isn't:
[...]
File "mesonbuild/interpreter.py", line 1759, in detect_compilers
comp.sanity_check(self.environment.get_scratch_dir(), self.environment)
File "mesonbuild/compilers.py", line 1279, in sanity_check
pe = subprocess.Popen(cmdlist, cwd=work_dir)
File "/usr/lib64/python3.5/subprocess.py", line 947, in __init__
restore_signals, start_new_session)
File "/usr/lib64/python3.5/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'java'
Clang++ doesn't allow that, but void* will always be allowed because
lots of projects depend on that.
error: cast from pointer to smaller type 'int' loses information
Need to pass -fpermissive to force C++ compilers to only warn about our
non-conformant code that tests for a symbol being defined.
Also do a simple #ifdef check first in has_header_symbol to allow
arbitrary macros to be detected which would not have been detected
earlier. This follows what AC_CHECK_DECL does.
Closes#958
* contributing: Use should instead of thould
* interpreter: Use exist_ok parameter in subdir function
We explicitly depend on python 3.4 or newer, which means the exist_ok
parameter is available. Use it instead of a try with a pass on except.
* authors: Add my name at the end of authors file
This is the common Python convention for private methods
so lets not expose these to build files as they are
implementation details and their behavior is undefined.
All assignments in meson should be by value, so mutable objects
(i.e. environment() and configuration_data()) should be copied
automatically on assignment.
Fixes#831.
We should only silently return from a dependency() call if the error is
transient (old version, wrap failed to download etc), not if the
subproject invocation or dependency name are incorrect.
For instance, if you use a dependency(..., fallback : ...) call in
a meson.build not in the root directory, we would always ignore the
call instead of erroring out due to invalid usage.
We should consider categorising our exceptions in this manner elsewhere
too.
If building in a prefix with a version of the library that's already
installed with other dependencies already installed in that prefix,
then the installed library was being picked up to link with
for gir generation instead of the newly built library.
If first checking for a dependency as not-required, and then later
checking for the same dependency again as required, we would not
error out saying the dependency is missing, but just silently
re-use the cached dependency object from the first check and then
likely fail at build time if the dependency is not actually there.
With test case.
Fixes#964.
Not all headers are public, or contain public types. GTK-Doc allows
adding headers to be ignored during the "scan" phase, by passing the
`--ignore-headers` command line argument to gtkdoc-scan.
Currently, you can do something like:
ignored_headers = [ 'foo-private.h', 'bar-private.h', ]
gnome.gtkdoc(...
scan_args: [
'--ignore-headers=' + ' '.join(ignored_headers),
],
...)
But it does not guarantee escaping rules and it's definitely not nice.
We can add a simpler version of that mechanism through a new positional
argument, `ignore_headers`, which behaves like `content_files` or
`html_assets`, and takes an array of header files to ignore:
gnome.gtkdoc(...
ignore_headers: ignored_headers,
...)
If a `<modulename>-overrides.txt` file exists in the docs directory it
means it's intended to be used in place of the one gtk-doc generates.
GLib and GTK+, for instance, ship with one because some of the types
they provide — like the thread primitives, or the platform macros —
contain architecture-dependent fields that should not be accessed
directly.
This commit should close the last bit of issue #550.
Make so both executable() targets that are marked as native and
external programs (which are usually build tools compiled for the
host machine) are not supposed to be run with the exe wrapper.
Every other build system does this, and at least OS X, iOS, and Android
depend on this to select the OS versions that your application is
targetting.
At the same time, just use a wrapper for self.run and self.links to
share the common (identical) code.
Seems better to do this since the behaviour is compiler-specific. Would
be easier to extend this later too in case we want to do more
compiler-specific things.
Simply placing a reference to it isn't enough for the linker to try and
think it's being used and do a symbol availability check with
-Wl,-no_weak_imports on OS X ld.
Nirbheek Chauhan
Patrick Griffis
Jussi Pakkanen
alvarez86
Tim-Philipp Müller
Matthew Waters
Scott D Phillips
Emmanuele Bassi
Mark Schulte
Guillaume Poirier-Morency