gimp/plug-ins/file-raw/meson.build

52 lines
1.3 KiB
Meson
Raw Permalink Normal View History

2017-11-01 14:27:13 +01:00
file_raw_exes = [
'file-another-rawtherapee',
2017-11-01 14:27:13 +01:00
'file-darktable',
'file-raw-placeholder',
'file-rawtherapee',
]
foreach plugin_name : file_raw_exes
plugin_sourcecode = [
2017-11-01 14:27:13 +01:00
plugin_name +'.c',
'file-raw-utils.c',
]
plugin_sources = plugin_sourcecode
2017-11-01 14:27:13 +01:00
if platform_windows
plugin_rc = configure_file(
Issue #7327: Cannot build GIMP3 on MSYS2 using Meson. This is untested on my side, because the bug only happens on native builds with meson (our CI has cross-builds with meson and native builds with autotools and I only do cross-builds locally) but I think/hope it will work. Basically we were using .full_path() because these rc files were also used as input of some configure_file() calls which doesn't like custom target objects as input (it wants strings or file objects). Yet a bug in meson didn't like the colon used in native Windows full paths ('C:' and such) when used in windows.compile_resources(). This has been fixed by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368 Yet we just cannot depend on very early meson (or worse dev meson code). On the other hand, if the input is a custom_tgt object, it uses the object ID which we give as first parameter of custom_target() so we know it's appropriately named without colons (such as 'gimp_plugins_rc'). Thus we should not bump into this issue again. For the few usage in configure_file(), I just add a .full_path() only when needed at call time. Last but not least, I replace the bogus `meson --version` call by a `python3 -c 'exit()'` as advised by Eli Schwartz: https://gitlab.gnome.org/GNOME/gimp/-/commit/2afa019c708869ef84a2d24c96552b380a504d4d#note_1284951 The reason is that it is apparently possible (or will be when some reimplementation of meson will be done) that the `meson` executable itself does not exist. On the other hand, `python3` should always be there, as a mandatory dependency of the build tool. In order to use an appropriate `python3`, I made the pythonmod.find_installation() check required in our build (which should not be a problem since it's a meson requirement as well), even when the -Dpython option is false (this one depends on other requirements too anyway, such as version and pygobject). This way I can call this meson variable of discovered python in my bogus call, instead of calling a (potentially different) python from PATH environment.
2021-10-12 16:00:33 +02:00
input : gimp_plugins_rc.full_path(),
2017-11-01 14:27:13 +01:00
output: plugin_name + '.rc',
copy: true,
)
plugin_sources += windows.compile_resources(
plugin_rc,
args: [
'--define', 'ORIGINALFILENAME_STR="@0@"'.format(plugin_name+'.exe'),
'--define', 'INTERNALNAME_STR="@0@"' .format(plugin_name),
'--define', 'TOP_SRCDIR="@0@"' .format(meson.project_source_root()),
2017-11-01 14:27:13 +01:00
],
include_directories: [
rootInclude, appInclude,
],
)
endif
plugin_exe = executable(plugin_name,
plugin_sources,
dependencies: libgimpui_dep,
win_subsystem: 'windows',
install: true,
install_dir: gimpplugindir / 'plug-ins' / plugin_name)
plugin_executables += [plugin_exe.full_path()]
2017-11-01 14:27:13 +01:00
endforeach
install_data([
'file-darktable-export-on-exit.lua',
'file-darktable-get-size.lua',
],
install_dir: prefix / gimpdatadir / 'file-raw',
)