dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/build/windows/meson.build

36 lines
1009 B
Meson
Raw Normal View History

Meson port.
2017-11-01 21:27:13 +08:00
# Windows specific
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
configure_file(
Meson port.
2017-11-01 21:27:13 +08:00
input : 'gimp-plug-ins.rc.in',
output: 'gimp-plug-ins.rc',
configuration: versionconfig,
)
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
configure_file(
Meson port.
2017-11-01 21:27:13 +08:00
input : 'gimp.rc.in',
output: 'gimp.rc',
configuration: versionconfig,
)
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
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
# Basically, the build rules below do nothing (a mere `python -c 'exit()'` call).
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
# But because they depends on `git-version.h`, meson ensure that it gets built first,
# Then the result of this targets is used in 35+ resource compiler build rules.
#
# Nasty trick indeed, but it fixes race condition issue described in GNOME/GIMP#6257.
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
gimp_plugins_rc = custom_target('gimp_plugins_rc',
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
build_by_default: true,
build_always_stale: true,
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
command: [python, '-c', 'exit()'],
meson: Fix build from tarball Since https://gitlab.gnome.org/GNOME/gimp/-/commit/2afa019c708869ef84a2d24c96552b380a504d4d, the Meson configure step will fail when building from tarball (missing `.git` and `gitversion.h` is present) because `gitversion_h` variable will contain a `list[file]` but `custom_target` does not like that in its `depends` kwarg.
2022-02-26 01:40:31 +08:00
depends: generate_version_h ? [gitversion_h] : [],
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
output: ['gimp-plug-ins.rc']
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
)
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
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
gimp_app_rc = custom_target('gimp_app_rc',
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
build_by_default: true,
build_always_stale: true,
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
command: [python, '-c', 'exit()'],
meson: Fix build from tarball Since https://gitlab.gnome.org/GNOME/gimp/-/commit/2afa019c708869ef84a2d24c96552b380a504d4d, the Meson configure step will fail when building from tarball (missing `.git` and `gitversion.h` is present) because `gitversion_h` variable will contain a `list[file]` but `custom_target` does not like that in its `depends` kwarg.
2022-02-26 01:40:31 +08:00
depends: generate_version_h ? [gitversion_h] : [],
build, meson: Fix rc files build order dependency... by adding special filler custom_target() build rules. Basically, these build rules do nothing (a mere meson --version call), but they ensure that `git-version.h` is built first, before the dependant rc files are used in respective resource compiler build targets. This still a nasty trick (not a proper solution), but it do the job. See #6257 for additional information.
2021-09-29 02:30:25 +08:00
output: ['gimp.rc']
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
)