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
There is basically no such word in english, "nonexistant".
American people use "nonexistent" and British people used
to have "non-existent", but some time ago they did away with
the hyphens, so there is only one option really: "nonexistent".
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
a) Don't search for pkg-config if we're only cross-compiling
b) Don't unconditionally error out while cross-compiling if the
specified pkg-config is not found and the dependency is optional
c) Use the pkg-config binary that was found in check_pkgconfig for the
actual testing
d) Use shutil.which on the found pkg-config only if it finds it.
Sometimes shutil.which fails to find it, for instance on Windows
with absolute paths.
When you pass an absolute path to shutil.which, it will not implicitly
append any extensions. This is problematic on Windows, so we need to
account for that.
This fixes detection of Qt tools on Windows which are searched with the
full path to the Qt bindir.
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`.
Also don't use `dependencies` as a module name since it is commonly used
as a variable name too. Instead, directly import the classes that we use
from that module.
In the case of subproject we will properly setup the --subdir argument
but the MESON_SUBDIR is never adapted and will point to an empty string
leading to the following backtrace when building `gst-build`:
msgfmt: error while opening "/home/thiblahute/devel/gstreamer/gst-build/af.po" for reading: No such file or directory
Traceback (most recent call last):
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 37, in <module>
sys.exit(main())
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 34, in main
return mesonmain.run(launcher, sys.argv[1:])
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 248, in run
sys.exit(run_script_command(args[1:]))
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 236, in run_script_command
return cmdfunc(cmdargs)
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 111, in run
if gen_gmo(src_sub, bld_sub, langs) != 0:
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 66, in gen_gmo
'-o', os.path.join(bld_sub, l + '.gmo')])
File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['msgfmt', '/home/thiblahute/devel/gstreamer/gst-build/af.po', '-o', '/home/thiblahute/devel/gstreamer/gst-build/build/af.gmo']' returned non-zero exit status 1
Failed to run install script: /usr/bin/python3 /home/thiblahute/devel/gstreamer/gst-build/meson/meson.py --internal gettext install --subdir=subprojects/gstreamer/po --localedir=share/locale --pkgname=gstreamer-1.0 --langs=af@@az@@be@@bg@@ca@@cs@@da@@de@@el@@en_GB@@eo@@es@@eu@@fi@@fr@@gl@@hr@@hu@@id@@it@@ja@@lt@@nb@@nl@@pl@@pt_BR@@ro@@ru@@rw@@sk@@sl@@sq@@sr@@sv@@tr@@uk@@vi@@zh_CN@@zh_TW
FAILED: install
'/usr/bin/python3' '/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py' '--internal' 'install' '/home/thiblahute/devel/gstreamer/gst-build/build/meson-private/install.dat'
This is more or less standardized way to have one variable which
will work for all buildsystems defined in redhat-rpm-config.
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
This avoids printing several 'Found:' messages during configure, and
also avoids doing several searches for the same binary. This is already
done by the interpreter for `find_program` calls from build files.
Also move it to the module-wide __init__.py file so it can be used by
other modules as-needed.
Also use it for g-ir-scanner where it was missed in one place, also fix
exception name in the same place.
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.
It is often useful to be able to check if a specific object is of a type
defined in a module. To that end, define all such targets in
modules/__init__.py so that everyone can refer to them without poking
into module-specific code.
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.
Without this, the user has to both compile the resource with
gnome.compile_resources, pass that to the target sources, and also
pass --gresources=/path/to/gres.xml to vala_args in the target.
With this, we will do that automatically.
If it isn't, the --target-glib check in generate_vala_compile will
iterate over the version_reqs as a string and fail to add the
--target-glib argument.
The same vapi or vala might be added multiple times. Don't freak out if
that happens. Only freak out if a vapi or vala generated source by the
same name and the output same path is added twice.
This should never happen anyway since we would refuse to create the
target in the first place in theory, but it might happen because of bugs
in generators and custom targets.
Closes#1084
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'
Using RPM's %{optflags} is definitely nice, but not enough. LDFLAGS
are not there, and idea of optflags is too generic. It is supposed
to work under CC and CXX, but apparently someone forgot that there
is difference between these two.
%__global_*flags is not part of RPM itself, it's coming within
redhat-rpm-config which makes our macros file not that portable,
but anyway we already have %__global_ldflags and %ninja_build and
no one complained.
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
When user uses %meson -Denable_cool_feature=true current macro fails
because RPM adds flag after popd:
...
pushd x86_64-redhat-linux-gnu
/usr/bin/meson ... $OLDPWD/.
popd -Denable_cool_feature
Since meson can accept $srcdir and $builddir arugments we don't have
this problem with pushd/popd. It also simplifies things a bit.
Reported-by: Richard Hughes <richard@hughsie.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=1401062
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
This is much more accurate since this is actually what determines what
file naming to use and whether there will be PDB debugging information
or not.
Closes#1169
This greatly improves the logic for determining the linker. Previously,
we would completely break if a target contained only extracted objects
and we were using more than one compiler in our project.
This also fixes determination of the linker if our target only contains
generated objc++ sources, and other funky combinations.
Jussi Pakkanen
Nirbheek Chauhan
Igor Gnatenko
Thibault Saunier
Sam Thursfield