After PR #2662, running test case common/125 shared module/ on Cygwin gets
me:
$ ninja -C _build
ninja: Entering directory `_build'
[7/7] Linking target prog.exe.
/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/../../../../x86_64-pc-cygwin/bin/ld: warning: --export-dynamic is not supported for PE+ targets, did you mean --export-all-symbols?
Also, fix doc for correct version of first apperance.
Future work: Notwithstanding the hint that ld gives, these options are not
equivalent, and it's not clear we should be using it here:
--export-all-symbols is the default behaviour, and if the exports are
restricted by explicit annotations or a .def file, this option might be
overriding that...
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
has_argument and other similar methods of compiler objects only support
checking compiler flags. If they are used to check linker flags, the
results are very likely to be wrong and developers should be warned.
Otherwise we will try to use the objc compiler when linking projects
with both objc and C++.
Technically we should use the objc++ linker when doing this, but on
most (all?) systems the objc++ linker is `c++`, which is the same
as the C++ linker.
Closes https://github.com/mesonbuild/meson/issues/2468
See issue #2762
Adds full_version to class Compiler. If set full_version will be printed
additionally.
Added support for CCompiler and CPPCompiler
Added support for gcc/g++, clang/clang++, icc.
We can't know if the .lib is a static or import library, but that's
a problem in general too. The only way to figure out if a specific
file is an import or a static library is to dump its symbols and check
if it starts with __imp or not.
Even then, some libs are hybrid import and static, i.e., they contain
references to DLLs for some symbols and also provide implementations
for other symbols so this is a difficult problem.
Closes https://github.com/mesonbuild/meson/issues/2659
As the Vala compiler does not define thread_flags() and
thread_link_flags(), depending on threads in any capacity will cause Meson to
fail.
Fixes#2720.
We can now specify the library type we want to search for, and whether
we want to prefer static libraries over shared ones or the other way
around. This functionality is not exposed to build files yet.
Auto detection was based on parsing gcc's output so we have to
ensure that it is always 'C'.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This method accepts a single function that takes no arguments and
returns a single value which can be a value that can be cast to
a 64-bit signed integer, or a string, and returns that value.
Mostly useful for running foolib_version() functions that return the
currently-available version of libraries.
Of course D compilers have different flags to set some important
D-specific settings. This adds a simple method to change these flags in
a compiler-agnostic way in Meson.
This replaces the previous `unittest_args` method with a more generic
variant.
Leon Krause