Correct version_compare_condition_with_min() for the case where no minimum
version is established by the version constraint. Add a simple test.
Also fix test_feature_check_usage_subprojects by escaping regex
metacharacters.
if |condition| is '<', '<=' or '!=', the minimum version satisfying the
condition is 0, so the minimum version for a feature is never met.
if |condition| is '>=' or '==', the minimum version satisfying the condition
is the version compared with, so the minimum version for a feature must be
less than or equal to that.
if |condition| is '>', the minimum version satisfying the condition is
greater than the version compared with, so the minimum version for a feature
must be less than that
(it's this last condition that makes this function necessary, as in all
other cases we could establish a definite minimum version which we could
compare to see if it's less than or equal to the current version)
Currently this trims '0.48.0.dev1' to '0.48.0', and then requires exactly
that version in the generated meson.build for the test.
Just use the exact version.
Also only use a 'project(meson_version:)' constraint in the generated
project if a version is specified
Also remove unused grab_leading_numbers
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.
Allows to manually reconfigure a project the same way backends would do
(e.g. ninja reconfigure). This has the advantage that new options can be
set using "meson --reconfigure -Dfoo=bar" and solve situations where a
project cannot be reconfigured because new options has been added with
the wrong default value.
Fixes#3543.
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.
The regression was introduced in my recent refactoring of
that method (8377ea4).
This commit simply restores the ordering of the generated
scan_command, ensuring `-lasan` and other internal linker
flags come before `--library` or `--program`
We now use the soversion to set compatibility_version and
current_version by default. This is the only sane thing we can do by
default because of the restrictions on the values that can be used for
compatibility and current version.
Users can override this value with the `darwin_versions:` kwarg, which
can be a single value or a two-element list of values. The first one
is the compatibility version and the second is the current version.
Fixes https://github.com/mesonbuild/meson/issues/3555
Fixes https://github.com/mesonbuild/meson/issues/1451
fixes#4032: meson now checks properly for the compiler used to compile dub dependencies
fixes#3568: applied the following patch https://paste.debian.net/1039317/
meson now adds flags for native dependencies required by dub modules
meson now checks for the D version implemented by the compiler used to build dub dependencies (execpt gdc which doesn't support this)
* The current version matching logic is brittle
with respect to Clang. LLVM and Apple Clang use
slightly different but nowadays overlapping
version ranges. Instead, we now just check whether
the compiler supports the given `-std=` variant
and try its respective fallback instead of
testing version ranges.
* Currently, RPATHs coming from dependencies and
`build_rpath` provided by the user might contain
the same path. Apple's `install_name` tool is
allergic to providing the same argument twice
when removing RPATHs:
error: install_name_tool: "-delete_rpath /usr/lib" specified more than once
Martin Kelly
Jon Turney
Alexey Rochev
Nirbheek Chauhan
Marcel Hollerbach
Thibault Saunier
Dylan Baker
Jussi Pakkanen
GoaLitiuM
Xavier Claessens
Jakub Wilk
Corentin Noël
Rafael Ávila de Espíndola
David Seifert
Alexis Jeandet
Mathieu Duponchelle
FFY00