It's only supported by few platforms when the linked file exists, while it
would cause an error otherwise.
In any case just implement this via an helper set_chmod function that will
handle the case where follow_symlinks is not supported by the platform
and will just not set any mod for the link itself (as it would otherwise
apply to the linked file).
Fixes#3914
Add test to verify the installation of broken symlinks when a default_umask
is set.
Reusing the same code of other test, thus sharing the actual test code
in a single function.
Fixed manually promoting wrap files with a full path, e.g.
`meson wrap promote subprojects/s1/subprojects/projname.wrap`,
which resulted in an error before (new test added:
`./run_unittests.py AllPlatformTests.test_subproject_promotion_wrap`).
Additionally, running promote with an invalid subproject path now fails
properly. Before, it just silently did nothing (added to test:
`./run_unittests.py AllPlatformTests.test_subproject_promotion`).
Extend test case for issue #3575 for Windows resource files with the same
name to cover the case where duplicate outputs exist due to use of
pathnames.
Also Test using file objects as well as literal filenames
g-ir-scanner is very picky about the flags that it can accept, so the
build fails on macOS if you have Framework external dependencies,
which add -F and -framework arguments.
Also fix incorrect de-duping of -framework arguments for gtkdoc.
Earlier, we would replace the subproject option with the parent
project's option, which is incorrect if the types are not the same.
Now we retain the subproject's option and print a warning. It's not
advisable to issue an error in this case because subproject option
yielding is involuntary for the parent project (option names can match
because of coincidences).
Appveyor CI gets backlogged for several hours at a time with the most
trivial of usage. Nuke it. It can be re-added if people really need it
and are willing to sponsor extra jobs on Appveyor.
I believe the intent (from 30d0c2292f) is
that `[binaries]` isn't needed just for "target-only cross" (build ==
host != target). This fixes the code to match that, hopefully clarifying
the control flow in the process, and also improves the message to make
that clear.
Shared modules may be resource-only DLLs, or might automatically
self-initialize using C constructors or WinMain at DLL load time.
When an import library is not found for a shared module, just print
a message about it instead of erroring out.
Fixes#3965
* Lookup is now performed according to the following order:
1. use `pkg-config` with `PKG_CONFIG_LIBDIR=LIBPC` from python
2. use plain `PKG_CONFIG_{LIBDIR,PATH}` from the environment
3. try to extract the information from SYSCONFIG
The second step is necessary for relocated python installations
and cross compilation scenarios, where the value of `LIBPC` might
be wrong.
Otherwise we get an error while checking the subproject version:
Uncomparable version string 'none'.
If the dependency was found as a not-found dependency in the
subproject and is not required, just take it.
Marco Trevisan (Treviño)
Daniel Pirch
Jon Turney
Jussi Pakkanen
Nirbheek Chauhan
Xavier Claessens
mohdamerkhalidi
Nirbheek Chauhan
John Ericson
Zachary Michaels
Mathieu Duponchelle
David Seifert
Charles Barto