This does two things:
* On windows GCC-like compilers, the subsystem is always explicitly
specified (either -mwindows or -mconsole). MSVC is already explicit.
* The gui_app linker flags are now added after those mandated by
external dependencies. This is because some misguided libraries (such
as SDL) think that hijacking `main()` and forcing `-mwindows` in link
flags is clever. We must unconditionally override such misuses to let
gui_app work as intended.
In addition to MSVC, which was worked around previously, GCC also does
not list includes from the PCH in the depfile by default, unless
-fpch-deps is given. I think it's best to stay safe and not rely on any
particular behavior from the compiler here.
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.
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.
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
A custom_target, if install is set to true, will always be built by
default even if build_by_default is explicitly set to false.
Ensure that this does not happen if it's set explicitly. To keep
backward compatibility, if build_by_default is not set explicitly and
install is true, set build_by_default to true.
Fixes#4107
Since trying to cross compile for Windows from Linux (WSL) and having
paths like this:
'-L/mnt/c/Program Files (x86)/Microsoft Visual Studio/2017/\
Community/VC/Tools/MSVC/14.15.26726/lib/x64'
I found that the spaces and brackets in the paths weren't properly
escaped by the Ninja backend.
Building a cross compiler (`build == host != target`) is not cross
compiling. As such, it doesn't make sense to handle it under
`is_cross_build`.
(N.B. Building a standard library for a cross compiler would require
cross compiling, but Meson has support to do such a thing as part of a
compiler build currently.)
Nicolas Schneider
David Vanderson
Andrei Alexeyev
jml1795
John Ericson
John Ericson
Michael Hirsch, Ph.D
Nirbheek Chauhan
Nicolas Schneider
Luca Boccassi
Jussi Pakkanen
Robert Bragg
Daniel Mensinger