eUgEntOptIc44/gimp
1
1
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-10-06 01:12:40 +02:00
Code Issues Releases Activity
Files
f09007507fd4e36a05424f57de664bb0e5ac4739
gimp/app/gegl/meson.build

62 lines
1.3 KiB
Meson
Raw Normal View History

Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
stamp_gegl_enums = custom_target('stamp-gimp-gegl-enums.h',
input : [
files(
'gimp-gegl-enums.h'
),
],
output: [ 'stamp-gimp-gegl-enums.h', ],
app, libgimp*: (meson) fix all the generated `*-enums.c`. More of the files were wrong, or at least not absolutely identical to the files generated by the autotools. I am not doing any code change other than trying to make both build systems produce identical files (except for slight differences on 2 files not worth the effort) even though maybe some things can be improved (especially on the include list). Maybe to be improved later. Also fixing 2 of the previously autotools-generated files because of space typos which should have been committed earlier. Finally it is to be noted that there is no logics to copy the generated files back to the source directory in the meson rules. I am not sure anyway this is really worth it and maybe we should just stop tracking these generated files eventually.
2019-10-19 22:18:50 +02:00
command: [
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
mkenums_wrap, perl,
meson: fix warnings of deprecated features. Now that we bumped our meson requirement, meson is complaining about several features now deprecated even in the minimum required meson version: s/meson.source_root/meson.project_source_root/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead. s/meson.build_root/meson.project_build_root/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead. Fixing using path() on xdg_email and python ExternalProgram variables: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
2022-08-31 01:07:27 +02:00
meson.project_source_root(), meson.current_source_dir(),
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
meson.current_build_dir(),
'gimp-gegl-',
'#include <gio/gio.h>\n' +
'#include "libgimpbase/gimpbase.h"\n' +
'#include "core/core-enums.h"\n',
'#include "gimp-intl.h"'
app, libgimp*: (meson) fix all the generated `*-enums.c`. More of the files were wrong, or at least not absolutely identical to the files generated by the autotools. I am not doing any code change other than trying to make both build systems produce identical files (except for slight differences on 2 files not worth the effort) even though maybe some things can be improved (especially on the include list). Maybe to be improved later. Also fixing 2 of the previously autotools-generated files because of space typos which should have been committed earlier. Finally it is to be noted that there is no logics to copy the generated files back to the source directory in the meson rules. I am not sure anyway this is really worth it and maybe we should just stop tracking these generated files eventually.
2019-10-19 22:18:50 +02:00
],
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
build_by_default: true
Meson port.
2017-11-01 14:27:13 +01:00
)
meson: Always enable CPU extensions Don't enable conditionally based on the buildtype. Further, don't use `add_project_arguments()` to enable the instructions: this will lead to crashes within g-ir-scanner, which can't properly parse these instructions. https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
2020-05-12 12:47:00 +02:00
libappgegl_loops = simd.check('gimp-gegl-loops-simd',
sse2: 'gimp-gegl-loops-sse2.c',
compiler: cc,
include_directories: [ rootInclude, rootAppInclude, ],
dependencies: [
cairo,
gegl,
gdk_pixbuf,
],
)
Meson port.
2017-11-01 14:27:13 +01:00
libappgegl_sources = [
'gimp-babl-compat.c',
'gimp-babl.c',
'gimp-gegl-apply-operation.c',
'gimp-gegl-loops.cc',
'gimp-gegl-mask-combine.cc',
'gimp-gegl-mask.c',
'gimp-gegl-nodes.c',
'gimp-gegl-tile-compat.c',
'gimp-gegl-utils.c',
'gimp-gegl.c',
'gimpapplicator.c',
'gimptilehandlervalidate.c',
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
'gimp-gegl-enums.c',
stamp_gegl_enums
Meson port.
2017-11-01 14:27:13 +01:00
]
libappgegl = static_library('appgegl',
libappgegl_sources,
meson: Always enable CPU extensions Don't enable conditionally based on the buildtype. Further, don't use `add_project_arguments()` to enable the instructions: this will lead to crashes within g-ir-scanner, which can't properly parse these instructions. https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
2020-05-12 12:47:00 +02:00
link_with: libappgegl_loops[0],
Meson port.
2017-11-01 14:27:13 +01:00
include_directories: [ rootInclude, rootAppInclude, ],
c_args: '-DG_LOG_DOMAIN="Gimp-GEGL"',
dependencies: [
meson: Always enable CPU extensions Don't enable conditionally based on the buildtype. Further, don't use `add_project_arguments()` to enable the instructions: this will lead to crashes within g-ir-scanner, which can't properly parse these instructions. https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
2020-05-12 12:47:00 +02:00
cairo,
gegl,
gdk_pixbuf,
Declare gexiv2 dependency on many targets (due to gimpmetadata.h) Our build files were relying 'sysroot' to find gexiv2.h but this is not possible with Apple Clang om which sysroot points to macOS SDK. So, exotic environments like Homebrew were failing. Let's fix this.
2025-08-21 15:18:02 -03:00
gexiv2
Meson port.
2017-11-01 14:27:13 +01:00
],
)
Copy Permalink