2017-11-01 21:27:13 +08:00
|
|
|
|
|
|
|
|
file_raw_exes = [
|
|
|
|
|
'file-darktable',
|
|
|
|
|
'file-raw-placeholder',
|
|
|
|
|
'file-rawtherapee',
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
foreach plugin_name : file_raw_exes
|
|
|
|
|
|
|
|
|
|
plugin_sources = [
|
|
|
|
|
plugin_name +'.c',
|
|
|
|
|
'file-raw-utils.c',
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
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 22:00:33 +08:00
|
|
|
input : gimp_plugins_rc.full_path(),
|
2017-11-01 21:27:13 +08: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.source_root()),
|
|
|
|
|
],
|
|
|
|
|
include_directories: [
|
|
|
|
|
rootInclude, appInclude,
|
|
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
executable(plugin_name,
|
|
|
|
|
plugin_sources,
|
2020-05-11 13:01:37 +08:00
|
|
|
dependencies: libgimpui_dep,
|
2017-11-01 21:27:13 +08:00
|
|
|
install: true,
|
|
|
|
|
install_dir: gimpplugindir / 'plug-ins' / plugin_name,
|
|
|
|
|
)
|
|
|
|
|
endforeach
|
|
|
|
|
|
|
|
|
|
install_data([
|
|
|
|
|
'file-darktable-export-on-exit.lua',
|
|
|
|
|
'file-darktable-get-size.lua',
|
|
|
|
|
],
|
|
|
|
|
install_dir: prefix / gimpdatadir / 'file-raw',
|
|
|
|
|
)
|