While at it, make more methods private by storing the version found on
the instance. That avoids having to call check_pkgconfig() as static
method from unittests.
This also makes it more consistent with get_pkgconfig_variable() which
always return empty value instead of failing when the variable does not
exist. Linking that to self.required makes no sense and was never
documented any way.
The Metrowerks assembler does not support optimization flags.
However, it received the same opt args as the Metrowerks C and C++
compilers, because it inherits from the 'MetrowerksCompiler' mixin.
This broke builds with opt level higher than 0 that used the Metrowerks
Assembler, as the latter received unsupported args. This is now fixed.
According to the Meson documentation, optimization level 3 should
set the highest possible optimization for the compiler in use.
In Metrowerks, this is 'O4,p'. However, Meson's Metrowerks
implementation mapped opt level 3 to '-O3'. This has been fixed.
The args were in both buildtype and optimization. This broke buildtypes other
than plain or custom unless manually setting the optimization level to
0, because Metrowerks chokes on duplicate arguments.
The interpreter takes significant amount of time to initialize
everything in project() function. We only need to extract a string from
AST, just like we do in handle_meson_version_from_ast().
FIXME: another approach would be to consider cont_eol as comment (i.e.
add backslash and whitespaces to the comment regex). In both cases it
works until we want to parse comments separately.
TODO?: handle eol_cont inside a string (to split long string without
breaking lines). Probably a bad idea and better to simply join a
multiline string.
Added to existing '/I' and '-I' extraction with '-isystem', '/clang:-isystem', '/imsvc', '/external:I', which are forms of 'system' header include search path options for gcc, clang, clang-cl, and cl (msvc).
Factored 3 separate 'extract_...(...)' functions into one since they were always called together on the same args; a new combined '_extract_nmake_fields(...)' func avoids repeated iterations and checks.
It was generating #include with the basename of every header file. That
assumes that every directory where there are headers are also included
into search path when compiling the .c file.
Change to use path relative to current subdir, which can be both in
build or source directory. That means that we assume that when the .c
file is compiled, the target has a include_directories pointing to the
directory where gnome.mkenum_simple() has been called, which is
generally '.' and added automatically.
Also fix type annotation to only allow str and File sources, other types
have never been working, it would require to iterate over custom target
outputs, etc.
Fixes: #7582
Allow macro_name to be speficied as a parameter to configure_file().
This allows C macro-style include guards to be added to
configure_file()'s output when a template file is not given. This change
simplifies the creation of configure files that define macros with
dynamic names and want the C-style include guards.
A standard C library may not exist for cross-compile
environments, thus the existence of <stdio.h> cannot be
guaranteed.
Use <stddef.h> instead, this header contains compiler-specific
defines thus it usually comes from the compiler.
You cannot listdir() a directory that doesn't exist. This header
directory may not exist if suitable devel packages in distros with
split devel packages, aren't installed.
In theory we could raise a suitable error here. But it would be
inconsistent -- we don't otherwise validate that the Qt include
directories exist, usually just assuming they do because the dependency
was found. And this is niche code inside a non-default special kwarg.
At least for pkg-config, it's probably a bug in the distro if pkg-config
files exist but the headers don't. The qmake status is less clear.
Avoiding a crash means that at the very least, if those headers are in
fact directly used by the project, an obvious compiler error occurs
instead of a noisy meson traceback.
Fixes#12214
- On Windows, it was not detected if include directory was an absolute
path to source directory, because of the mis of path separators.
- In the edgecase the include directory begins with the exact same
string as the source directory, but is a different directory, it was
falsely reported as an error.
Fixes#12217.