Ignore warning 2282 about GCC pragmas since they are emitted in system
headers and are extremely spammy. They are emitted because ICC pretends
to be GCC via C macros but doesn't implement some pragmas.
https://bugzilla.gnome.org/show_bug.cgi?id=776562
Also, append to LD_LIBRARY_PATH because ICC uses that for some internal
libraries such as libintlc.so.
Explicitly warn with the `#warning` macro to ensure that ICC emits
a warning since ICC does not emit a warning for unused variables.
Also makes the test more reliable with other compilers.
Cache the absolute dir that the script is searched in and the name of
the script. These are the only two things that change.
Update the test to test for both #1235 and the case when a script of the
same name is in a different directory (which also covers the subproject
case).
Closes#1235
This is useful in many cases where the list of files cannot be known in
advance and is just dumped inside a directory. For example when
generating documentation with doxygen and other tools that we don't have
built-in support for.
Includes a test for the same.
Closes#893
Since we're checking for the existence of a header, just running the
preprocessor is enough. According to my benchmarks, doing this makes the
test roughly 2x faster.
I'm sure this will be useful for other checks too in the future.
This shaves off 7% on the configure time for glib on my machine.
This also fixes the issue that we had earlier where you had to specify
any extra headers needed to resolve symbols in the header being checked
for with `prefix`.
To use these, you just need to add the .vapi file to your target as
a source.
This test specifically tests that hand-written vapis referring to
C headers work.
Test that the --target-glib= argument while compiling Vala files is set
properly by using a feature (GtkTemplate) that requires glib >=2.38.
At the same time, also test that the appropriate gresource arguments are
also set for Vala targets. For each gresource.xml that is compiled, we
must pass --gresources=path/to/gresource.xml to valac.
With current Meson, this fails to configure with the following error:
Duplicate output 'dependency-generated/enum-types.h' from
'CustomTarget' 'enum-types.h'; conflicts with
'dependency-generated/enum-types.h' from 'CustomTarget'
'enum-types.h'
Also add MSVC support while doing so. Doesn't test 32-bit Windows yet
because I can't figure out how to do manual setup for function calls on
Win32 which also does symbol mangling. But this is fine for now.
We were checking for builtins explicitly like this because the ordinary
checks don't work for builtins at all. We do exactly the same check as
Autoconf and it doesn't work with Autoconf either (Autoconf is broken!)
So now we check for it in two ways: if there's no #include in prefix, we
check if `__builtin_symbol` exists (has_function allows checking for
functions without providing includes). If there's a #include, we check
if `symbol` exists.
The old method was causing problems with some buggy toolchains such as
MSYS2 which define some builtins in the C library but don't expose them
via headers which meant that `__builtin_symbol` would be found even
though `symbol` is not available.
Doing this allows people to always get the correct answer as long as
they specify the includes that are required to find a function while
also not forcing people to always specify includes to find a function
which is cumbersome.
Closes#1083
On Windows, we can build with both 32-bit and 64-bit compilers, but the
Python is either 32-bit or 64-bit. Check the architecture of the found
Python libraries and don't use them if they don't match our
build_machine.
Also skip the tests if the Python 3 dependency is not found.
Unlike Linux and OS X, when a library is loaded, all the symbols aren't
loaded into a single namespace. You must fetch the symbol by iterating over
all loaded modules.
So, we shouldn't use /FORCE:UNRESOLVED since that is not what modules do
on Windows. Instead, we now do exactly what GModule does on Windows.
Also use `void` for functions that take no arguments.
This is already how it should've been, but:
a) The test for this was wrong since Dependency is a base class for all
dependencies and isinstance on an InternalDependency will also be true
b) Internal dependencies can't ever be used here anyway because compiler
checks are always run at configure time and internal dependencies are
only built after that.
Just checking that the version retrieved from the pkg-config file
matches is not enough. It's nearly tautological since it just checks
that we aren't returning garbage in dep.version(). Instead, check in the
test executable that the pkg-config version retrieved matches the
ZLIB_VERSION exported by zlib.
Also don't require zlib 1.2.8 since RHEL (EPEL) 7 still has 1.2.7 and we
don't really need 1.2.8 anyway.
Nirbheek Chauhan
Jussi Pakkanen
Igor Gnatenko
Elliott Sales de Andrade
Sam Thursfield