Pre/PostBuildEvents do not run if no other build steps are out-of-date.
For most run targets (including install and test) that have no other
build steps, VS considers these to be always up-to-date after they have
been built once.
On the other hand, CustomBuild has clearly defined inputs and outputs
that define whether the target is up-to-date or not. By using a
nonexistent file as output of CustomBuild, it is always considered
out-of-date.
This aligns the VS behavior with ninja. `ninja install` unconditionally
installs, `ninja test` always runs the tests, and a run target always
gets executed, without any checks whether it is up-to-date or not.
Previously, this was only added to C/C++ targets, but not for others.
Thus, if you'd change a setting through `meson configure`, this was not
picked up, e.g. the install target said it was up-to-date and when force
rebuilding it, it also did not use the new settings until the build dir
was manually reconfigured.
Mypy struggles with the imperative form of Enum declaration, and
upstream doesn't consider it a bug, they recomend using the class form
for enums that are going to be externally exposed.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
If the global gdb option of mesontest is disabled (e.g. not set '--gdb')
and the gdb option of test_setup is enabled, an exception will be thrown.
Because signal.signal function can only be called from the main thread.
If attempting to call it from other threads will cause a ValueError exception to be raised.
Fix 'not founded' message for packages with another name for
specific configurations instead of just 'library'.
Signed-off-by: Luís Ferreira <lsferreira169@gmail.com>
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
When building for iOS, the Qt binaries only contain static libraries
and headers. No framework.
With this, Meson can successfully compile and link to Qt on iOS
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
Instead of only doing a naive filesystem search, also run the linker
so that it can tell us whether the -F path specified actually contains
the framework we're looking for.
Unfortunately, `extraframework` searching is still not 100% correct in
the case when since we want to search in either /Library/Frameworks or
in /System/Library/Frameworks but not in both. The -Z flag disables
searching in those prefixes and would in theory allow this, but then
you cannot force the linker to look in those by manually adding -F
args, so that doesn't work.