Put cygwin filemode tests back under the sourcedir
Remove inheritable permissions from the sourcedir
For :reasons:, the unit tests which check file mode were built in the
tempdir.
Instead, remove inheritable permissions from the working directory
(which the GitHub VM image has set for some reaons), since they can
interfere with getting exactly the file mode you asked for.
Partially reverts 04ae1cfb79
(cherry picked from commit f164ec692f)
This allows checking for tools that may not be available in older version of qt
or avoiding requesting tools that may not be necessary for a given project
Co-authored-by: Nirbheek Chauhan <nirbheek@centricular.com>
On Arch's shiny new 48-core/96-thread build server, the
`test_install_log_content` test fails because of an unexpected
`invalid-symlink.txt` file. Apparently the test runs in parallel with
`test_install_subdir_symlinks`, which modifies the `59 install subdir`
source directory.
To fix this, make `install_subdir_invalid_symlinks` copy the entire test
into a tmpdir before modifying it.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This was originally added for vala only, with the rationale that vala
generates bad code that has warnings. Unfortunately, the rationale was
fatally flawed. The compiler warns about a number of things, which the
user can control depending on their code (or their code generator's
code), but some of those things are absolutely critical to warn about.
In particular, GCC 14 and clang 17 are updating their defaults to warn
-- and error by default for -- invalid C code that breaks the standard,
but has been silently accepted for over 20 years "because lots of people
do it". The code in question is UB, and compilers will generate faulty
machine code that behaves erroneously and probably has a mass of CVEs
waiting to happen.
Compiler warnings are NOT safe to just... universally turn off. Compiler
warnings could be either:
- coding style lints
- threatening statements that the code is factually and behaviorally wrong
There is no magic bullet to ignore the former while respecting the
latter. And the very last thing we should ever do is pass `-w`, since
that causes ALL warnings to be disabled, even the manually added
`-Werror=XXX`.
If vala generated code creates warnings, then the vala compiler can
decrease the log level by generating better code, or by adding warning
suppression pragmas for *specific* issues, such as unused functions.
While at it, make more methods private by storing the version found on
the instance. That avoids having to call check_pkgconfig() as static
method from unittests.
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
By specifiying explicit encodings, we can silence warnings like:
/__w/meson/meson/test cases/common/100 postconf with args/postconf.py:15: EncodingWarning: 'encoding' argument not specified
with open(input_file) as f:
in CI.
This fixes regression caused by
3162b901ca
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
Case 1:
- Prog links to static lib A
- A link_whole to static lib B
- B link to static lib C
- Prog dependencies should be A and C but not B which is already
included in A.
Case 2:
- Same as case 1, but with A being installed.
- To be useful, A must also include all objects from C that is not
installed.
- Prog only need to link on A.
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
We use a dummy project with a vague name and try to find flags for it
based on the installable pkg-config files. This sort of works,
generally, because it attempts to match `-lct` which doesn't exist
because the test case isn't installed, and that link argument is passed
directly through.
Except, sometimes that library does exist. It is provided by the
"freetds" project, which may be a dependency other tools. In that case,
Meson finds a library, and the `dependency()` resolves to
`/usr/lib/libct.so` and the test fails.
Fortunately, we do have an API to say that we really want to get back
the same flags pkg-config returned. Use this.
This removes the need for the use of the global statement. I've also
updated the test that overrides this to use mock.patch instead of hand
monkey patching.
This is wasteful and generally unneeded, since code can just use the
compiler they detected instead of manually poking at the internals of
this subpackage.
It also avoids importing an absolute ton of code the instant one runs
`from . import compilers`
This is generally a bad idea, e.g. it causes OSError on freebsd.
It also gets ignored by solaris and thus causes unittest failures.
The proper solution is to simply reject any attempt to set this, and log a
warning.
The install_emptydir function does apply the mode as well, and since it
is a directory it actually does something. This is the only place where
we don't reset the mode.
Although install_subdir also installs directories, and in theory it
could set the mode as well, that would be a new feature. Also it doesn't
provide much granularity and has mixed semantics with files. Better to
let people use install_emptydir + install_subdir.
Fixes#5902
This was already skipped when running on the Ubuntu 18.04 version of gcc,
but it also fails with gcc 8.3.0 on Debian 10. Instead of hard-coding
specific versions to look for, do a version comparison.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The new get_env() method that returns an EnvironmentVariables object
will be needed in next commit that will pass it to CustomTarget.
This has the side effect to use the proper os specific path separator
instead of hardcoding `:`. It is the obvious right thing to do here, but
has caused issues in the past. Hopefully issues have been fixed in the
meantime. If not, better deal with fallouts than keep doing the wrong
thing forever.
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Qt now has official guidance for the symlinked names of the tools, which
is great.
Qt now officially calls the tools `fooX` instead of `foo-qtX` where the
major version of Qt is X. Which is not great, because a bit of an
unofficial standard had prior art and now needs to change, and we never
adapted.
Prefer the official name whenever looking up qmake, and in the
testsuite, specifically look only for the official name on versions of
qt which we know should have that.
Jon Turney