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

48 lines
1.0 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-02 01:08:35 +08:00
stamp_text_enums = custom_target('stamp-text-enums.h',
input : [
files(
'text-enums.h'
),
],
output: [ 'stamp-text-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-20 04:18:50 +08: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-02 01:08:35 +08: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 07:07:27 +08: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-02 01:08:35 +08:00
meson.current_build_dir(),
'text-',
'#include <gio/gio.h>\n' +
'#include "libgimpbase/gimpbase.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-20 04:18:50 +08: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-02 01:08:35 +08:00
build_by_default: true
Meson port.
2017-11-01 21:27:13 +08:00
)
libapptext_sources = [
'gimpfont.c',
'gimpfontfactory.c',
'gimptext-compat.c',
'gimptext-parasite.c',
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 13:07:57 +08:00
'gimptext-path.c',
Meson port.
2017-11-01 21:27:13 +08:00
'gimptext-xlfd.c',
'gimptext.c',
'gimptextlayer-transform.c',
'gimptextlayer-xcf.c',
'gimptextlayer.c',
'gimptextlayout-render.c',
'gimptextlayout.c',
'gimptextundo.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-02 01:08:35 +08:00
'text-enums.c',
stamp_text_enums
Meson port.
2017-11-01 21:27:13 +08:00
]
libapptext = static_library('apptext',
libapptext_sources,
include_directories: [ rootInclude, rootAppInclude, ],
c_args: '-DG_LOG_DOMAIN="Gimp-Text"',
dependencies: [
gegl, gdk_pixbuf, harfbuzz, pangocairo, pangoft2,
],
)