On Deban, and assuming now on Ubuntu as well, pip3 is only available after installing the python3-pip package. For that case explicitly specified the package during the system installation.
The problem with the earlier position of the generation code was, that
the results could not be cached, because the list of all link_deps was
overall different. However, it shared a special kind of subsets with
other build build targets.
Generating the set of subdirs that are required for linking, alongside
with the link dependencies brings the possibility of caching this.
This reduces the buildting from 1 min. in efl down to 20 sec. And
reduces the amount of 30872534 calls down.
this saves ~40 sec.
Always honour any windres setting in cross-file (we can't be compiling with
msvc, but this should apply when cross-compiling using gcc or clang)
Always honour WINDRES environment variable
Otherwise look for the resource compiler which is part of the same toolset
as the C or C++ compiler.
Add some commentary on why the conventions for compiled resource file
extensions differ between RC and windres
Also don't try to report non-existent path when we couldn't find the
resource compiler.
It's fairly common on Linux and *BSD platforms to check for these
attributes existence, so it makes sense to me to have this checking
build into meson itself. Autotools also has a builtin for handling
these, and by building them in we can short circuit cases that we know
that these don't exist (MSVC).
Additionally this adds support for two common MSVC __declspec
attributes, dllimport and dllexport. This implements the declspec
version (even though GCC has an __attribute__ version that both it and
clang support), since GCC and Clang support the MSVC version as well.
Thus it seems reasonable to assume that most projects will use the
__declspec version over teh __attribute__ version.
Fixes:
meson.build:6:0: ERROR: Uncomparable version string 'unknown'.
This was previously partially fixed in a8694f4b, which only fixed it
for cached fallback dependencies.
This makes any warning message printed by meson raise an exception,
intended to be used by CI and developpers to easily catch deprecation
warnings and other potential issues.
Somehow I overlooked this class when adjusting everything else in c59ec874
et seq.
Update Python3Dependency so it has a _factory() method which returns a list
of constructors, depending on the method: kwarg, which integrates better
with the reporting in find_external_dependency()
This ensures the return of a PkgConfigDependency object, if the dependency
is found with pkgconfig, so we don't have to specifically implement
get_pkgconfig_variable() ourselves.
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
Otherwise, git fiddles with the cmd.exe console's color behaviour and
disables it, which causes it to stop interpreting ANSI color codes
outputted by meson for colored output.
Effectively, as soon as any subproject is initialized, cmd.exe goes
nice coloured output to ugly raw ANSI codes.
Will Thompson