| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
|
|
It turns out we don't generally need to proxy every compiler ever
through the top-level package. The number of times we directly poke at
one is negligible and direct imports are pretty clean.
|
|
In the debug logs, always log if a dependency lookup raises a
DependencyException. In the `required: false` case, this information
would otherwise disappear forever, and we would just not even log that
we tried it -- it doesn't appear in "(tried x, y and z)".
In the `required: true` case, we would re-raise the first exception if
it failed to be detected. Update the raise message with the same
information we print to the debug logs, indicating which dependency and
which method was used in the failing attempt.
|
|
functools.partial preserves information about how the method was
created, lambdas do not. Also, we just want to freeze the first argument
and forward the rest anyway.
This also lets us get rid of a mypy error that was being ignored.
|
|
It doesn't really need class instantiation to just know what type it is,
and this way we can get the information early if a dependency fails to
init.
|
|
A bunch of SystemDependency subclasses overrode log_tried() even though
they used the same function anyway. Delete them -- they still print
the same thing either way.
|
|
We use `__future__.annotations` to good effect everywhere we can, and
one of the effects of this is that annotations are automatically
stringized and don't need to be evaluated, using less memory and
computation. But this only affects actual annotations -- a cast is just
a function with an argument, so the compiler has no idea that it's an
annotation to be stringized.
Do this manually.
|
|
|
|
|
|
This is needed for 6.1 support as noted in commit
a606ce22eb0dd05eef56384d59954edad7da131d but at the time there was no
pkg-config detection method at all. The stub code for Qt6 didn't support
libexecdir at all, and the pkg-config files added to newer versions of
Qt6 didn't export that information either until a further bugfix release.
Enforce that this information is required.
|
|
Add correct reading of pkgconfig-announced bindir and
pkgconfig-announced libexecdir. Will work only on 6.3+
|
|
In a bunch of places we need to list various types of libraries
including custom_target outputs, and it gets very long. Use a common
T.Union for this.
|
|
|
|
|
|
Along the way, add __future__ annotations where lacking.
|
|
It's a `List[str | int]`, just like in the build module. In fact, we
should probably share the same type information between the two.
|
|
Since a SharedLibrary can't be statically linked in, we shouldn't allow
the method to complete.
|
|
- `BuildTarget` should be `SharedLibrary | StaticLibrary`
- Needs to take `CustomTargetIndex` as well as `CustomTarget`
- don't assign to self until values have been converted to the correct
type
|
|
|
|
If we encounter a file under the Boost library directory that doesn't
look like a Boost library binary, we should ignore it.
We log a warning for each file we ignore, except for ones we know are
safe to ignore (e. g. PDB files from the SourceForge Windows
distribution). This should avoid polluting the log.
Fixes #8325.
|
|
By default, meson will try to look for shared libraries first before
static ones. In the meson.build itself, one can use the static keyword
to control if a static library will be tried first but there's no simple
way for an end user performing a build to switch back and forth at will.
Let's cover this usecase by adding an option that allows a user to
specify if they want dependency lookups to try static or shared
libraries first. The writer of the meson.build can manually specify the
static keyword where appropriate which will override the value of this
option.
|
|
In a couple of spots, kwargs.get('static', False) was being
unneccesarily used. In these spots, we can just use self.static instead
which is already inherited from the ExternalDependency. In additional,
the python system dependency oddly has a kwargs.get('static', False)
line which overrides the self.static in that dependency for no real
reason. Delete this line too.
|
|
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Extract to a separate function the code that resolves dependencies
for compiler methods. We will reuse it for add_project_dependencies().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
dependencies: allow get_variable to expose files from subprojects
|
|
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.
|
|
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
|
|
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.
|
|
Fixes regression in commit c211fea51389728783cf59ae41156a5e0de9c41a. The
original dependency lookup looked for `qmake-{self.name}`, i.e.
`qmake-qt5`, but when porting to config-tool, it got switched to
`qmake-{self.qtname}` i.e. `qmake-Qt6`, which was bogus and never
worked. As a result, if `qmake-qt5` and `qmake` both existed, and the
latter was NOT qt5, it would only try the less preferred name, and then
fail.
We need to define self.name early enough to define the configtool names,
which means we need to set it before running the configtool __init__()
even though configtool/pkgconfig would also set it to the same value.
Mark the tests as passing on two distros that were failing to detect
qmake due to this issue, and were marked for skipping because we assumed
that the CI skipping there was an expected case rather than an old
regression.
|
|
Qt 6.1 moved the location of some binaries from QT_HOST_BINS to
QT_HOST_LIBEXECS as noted in the changelog:
c515ee178f Move build tools to libexec instead of the bin dir
- Tools that are called by the build system and are unlikely to be
called by the user are now installed to the libexec directory.
https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/6.1.0/release-note.txt
It's possible to help the 'qt' module find the tools by adding Qt's
libexec directory to the PATH environment variable, but this manual
workaround is not ideal.
To compensate, meson now needs to look for moc, rcc, uic, etc. in
QT_HOST_LIBEXECS as well as QT_HOST_BINS.
Co-authored-by: Stefan Hajnoczi <stefanha@jammr.net>
|
|
|
|
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
|
|
Looks like boost dependency mixes up it's compiler and linker argument
order when it is removing duplicates (?) from those. This causes
unnecessary recompilations of everything depending on those components.
Use OrderedSet to remove the duplicates while also maintaining
consistent order for them.
|
|
- fix the research of target built by DUB
- explicitely state that DUB dynamic libraries and source libraries are not supported (yet) (mesonbuild#6581)
- fix the build settings of recipes having sub-dependencies (mesonbuild#7560)
- fix winlibs added from dub recipe
- sanitization, comments, explanations...
|
|
Structured Sources
|
|
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
|
|
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
|
|
A bunch of files have several T.TYPE_CHECKING blocks that each do some
things which could just as well be done once, with a single `if`
statement. Make them do so.
|
|
|
|
cmake: Add TARGET_ generator expression support (fixes #9305)
|
|
This allows someone to link against libjvm.so and libjawt.so.
|
|
|
|
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
|
|
It's a dumb check which doesn't know the difference between python
functions and string data. Work around this by changing the message
output to not include an opening parenthesis, and changing other similar
strings the same way for consistency.
|
|
All these dependencies are impossible to find on versions of Meson older
than the ones they got custom lookups in, because they don't provide
pkg-config files. So they should not / cannot be reasonably used on
older versions, and it is easy to say "yep, these should emit a
FeatureNew for the versions they got added in".
|
|
It would be too difficult and probably a layering violation to give an
interpreter handle to the inner guts of every dependency. What we can do
instead is let every dependency track:
- the Feature checks it can produce,
- the version attribute for when it was implemented
while leaving the interpreter in charge of actually emitting them.
|
|
This header is required anyway. And the compile test for linking to libc
with the gettext symbol, can succeed when we try to use the literal
symbol name without includes, but fail later during project build,
because actually including libintl.h might redefine the function to match
a forked symbol. This happens when GNU libintl is installed as a
standalone library on systems that have a less fully-featured gettext
implementation.
So, by including the header in has_function, we can ensure that we test
against the default resolved header. In the event that the symbol which
is #define'd by the header is 'libintl_gettext', linking will fail against
libc even when a builtin gettext does exist, and we will fall back to the
intl dependency that provides -lintl (and which is needed to properly
use the default header).
Of course, even that probably won't work.
has_function(prefix: '...') is useless to check the difference between
builtins and external library functions. It has code to detect
"builtins" that misfires in some cases (previously seen with iconv_open).
Instead compile an open-coded test file that this intl dependency
implementation fully controls, that doesn't get up to imaginative edge
cases like trying to find `__builtin_gettext`.
It's the only way to be sure.
Fixes compiling against the intl dependency on e.g. Alpine Linux when the
libintl package is installed.
|
|
|
|
|
