GIMP issueshttps://gitlab.gnome.org/GNOME/gimp/-/issues2022-04-17T13:01:12Zhttps://gitlab.gnome.org/GNOME/gimp/-/issues/3826[meson] Allow "incremental" installs by adding targets2022-04-17T13:01:12ZSalamandar[meson] Allow "incremental" installs by adding targetsWe should add targets that install well-chosen files to allow incremental installs just like Autotools allows us to do for now.
It's been discussed in !1 but that will be easier here.We should add targets that install well-chosen files to allow incremental installs just like Autotools allows us to do for now.
It's been discussed in !1 but that will be easier here.3.2https://gitlab.gnome.org/GNOME/gimp/-/issues/8033Pass warning_level to 2 in meson build2022-04-01T18:57:34ZdarnuriaPass warning_level to 2 in meson buildBy default meson only compile with `-Wall` passing to `warning_level=2` promote to `-Wextra`.
Add a loooot of messages during compilation:
Info about warning_level: https://mesonbuild.com/Builtin-options.html#By default meson only compile with `-Wall` passing to `warning_level=2` promote to `-Wextra`.
Add a loooot of messages during compilation:
Info about warning_level: https://mesonbuild.com/Builtin-options.html#Futurehttps://gitlab.gnome.org/GNOME/gimp/-/issues/8624Build fails to run pdbgen when pdb/groups/foo.pdb is touched2024-03-22T11:36:04ZLloyd Konnekerkonnekerl@gmail.comBuild fails to run pdbgen when pdb/groups/foo.pdb is touchedReplicate:
- edit say pdb/groups/context.pdb
- start a meson build
Expect: pdbgen to be run and generate new source files /app/pdb/context_cmds.[c,h] and libgimp/gimpcontext_pdb.[c,h]
Actual: it doesn't, and for example, ...Replicate:
- edit say pdb/groups/context.pdb
- start a meson build
Expect: pdbgen to be run and generate new source files /app/pdb/context_cmds.[c,h] and libgimp/gimpcontext_pdb.[c,h]
Actual: it doesn't, and for example, PDB Browser shows old documentation.
At least this happens some of the time, i.e. the issue may be intermittent.
Also, I think that only pdb/meson.build should "know" i.e. define what files pdbgen is generating.
As is, libgimp/meson.build and app/pdb/meson.build define the lists of what pdbgen is generating.
The principle is: only in one place, and related stuff together, i.e. hide the details of generation.
Libgimp/meson.build should only know that there is a list of generated files, and shouldn't define the list.
This is a separate enhancement, but might be related.https://gitlab.gnome.org/GNOME/gimp/-/issues/9481build failure on master with clang 16 in goat-exercise-vala.vala2024-01-26T19:59:09ZJacob Boeremabuild failure on master with clang 16 in goat-exercise-vala.valaTesting on Windows the CLANG64 profile of MSYS64 with meson and the master branch. This just updated the clang version to 16.0.4. Last time I checked was with clang v. 15 and that had no errors (after applying certain patches that are al...Testing on Windows the CLANG64 profile of MSYS64 with meson and the master branch. This just updated the clang version to 16.0.4. Last time I checked was with clang v. 15 and that had no errors (after applying certain patches that are also needed for v.16).
The specific error suggests that something needs changing in our vala goat exercise:
```
ninja: build stopped: subcommand failed.
[6/8] Compiling C object extensions/goat-exercises/goat-exercise-vala.exe.p/meson-generated_goat-exercise-vala.c.obj
FAILED: extensions/goat-exercises/goat-exercise-vala.exe.p/meson-generated_goat-exercise-vala.c.obj
"cc" "-Iextensions/goat-exercises/goat-exercise-vala.exe.p" "-Iextensions/goat-exercises" "-I../../gimp/extensions/goat-exercises" "-I." "-I../../gimp" "-Ilibgimp" "-I../..
/gimp/libgimp" "-ID:/msys64/home/Jacob/gimp/libgimp" "-ID:/msys64/clang64/include/gtk-3.0" "-ID:/msys64/clang64/include/pango-1.0" "-ID:/msys64/clang64/include/glib-2.0" "-
ID:/msys64/clang64/lib/glib-2.0/include" "-ID:/msys64/clang64/include/harfbuzz" "-ID:/msys64/clang64/include/freetype2" "-ID:/msys64/clang64/include/libpng16" "-ID:/msys64/
clang64/include/fribidi" "-ID:/msys64/clang64/include/cairo" "-ID:/msys64/clang64/include/pixman-1" "-ID:/msys64/clang64/include/gdk-pixbuf-2.0" "-ID:/msys64/clang64/includ
e/webp" "-ID:/msys64/clang64/include/atk-1.0" "-ID:/msys64/home/Jacob/prefix-gimp-clang64/include/gegl-0.4" "-ID:/msys64/clang64/include/gio-win32-2.0" "-ID:/msys64/clang64
/include/json-glib-1.0" "-ID:/msys64/home/Jacob/prefix-gimp-clang64/include/babl-0.1" "-fcolor-diagnostics" "-D_FILE_OFFSET_BITS=64" "-w" "-O2" "-g" "-Wabsolute-value" "-Wd
eclaration-after-statement" "-Wenum-conversion" "-Wliteral-conversion" "-Wno-strict-prototypes" "-Wold-style-definition" "-Wparentheses-equality" "-W#pragma-messages" "-Wso
metimes-uninitialized" "-Wtautological-unsigned-enum-zero-compare" "-Wunneeded-internal-declaration" "-Wunused-function" "-Wunused-value" "-Werror=implicit-function-declara
tion" "-fdiagnostics-show-option" "-fno-common" "-Wformat" "-Wformat-security" "-Winit-self" "-Wmissing-declarations" "-Wmissing-format-attribute" "-Wpointer-arith" "-Wretu
rn-type" "-Wtype-limits" "-DHAVE_CONFIG_H" "-DLIBDEFLATE_DLL" "-DGETTEXT_PACKAGE=\"org.gimp.extension.goat-exercises\"" -MD -MQ extensions/goat-exercises/goat-exercise-vala
.exe.p/meson-generated_goat-exercise-vala.c.obj -MF "extensions/goat-exercises/goat-exercise-vala.exe.p/meson-generated_goat-exercise-vala.c.obj.d" -o extensions/goat-exerc
ises/goat-exercise-vala.exe.p/meson-generated_goat-exercise-vala.c.obj "-c" extensions/goat-exercises/goat-exercise-vala.exe.p/goat-exercise-vala.c
../../gimp/extensions/goat-exercises/goat-exercise-vala.vala:42:112: error: incompatible function pointer types passing 'GimpValueArray *(GimpProcedure *, GimpRunMode, Gimp
Image *, gint, GimpDrawable **, GimpValueArray *, gpointer)' (aka 'struct _GimpValueArray *(struct _GimpProcedure *, GimpRunMode, struct _GimpImage *, int, struct _GimpDraw
able **, struct _GimpValueArray *, void *)') to parameter of type 'GimpRunImageFunc' (aka 'struct _GimpValueArray *(*)(struct _GimpProcedure *, GimpRunMode, struct _GimpIma
ge *, int, struct _GimpDrawable **, const struct _GimpValueArray *, void *)') [-Wincompatible-function-pointer-types]
_tmp0_ = (GimpImageProcedure*) gimp_image_procedure_new ((GimpPlugIn*) self, name, GIMP_PDB_PROC_TYPE_PLUGIN, _goat_run_gimp_run_image_func, g_object_ref (self), g_
object_unref);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gimp/libgimp/gimpimageprocedure.h:88:66: note: passing argument to parameter 'run_func' here
GimpRunImageFunc run_func,
^
1 error generated.
ninja: build stopped: subcommand failed.
```
Adding `'-Wno-error=incompatible-function-pointer-types'` to `warning_cflags_common` in meson.build makes the build succeed, and the vala exercise works as expected.
However, it would be good if someone with vala experience looked at ways to make this error/warning go away.https://gitlab.gnome.org/GNOME/gimp/-/issues/9705g-ir-scanner fails to build on older MacOS 10.132024-03-22T13:42:58ZLloyd Konnekerkonnekerl@gmail.comg-ir-scanner fails to build on older MacOS 10.13g-ir-scanner stops with assertion failed: ...vtable.unit_get_identifier != NULL
On MacOS 10.13 High Sierra circa 2017, the earliest that Apple still supports.
A Macports build using a Portfile similar to the Gimp official one.
This issu...g-ir-scanner stops with assertion failed: ...vtable.unit_get_identifier != NULL
On MacOS 10.13 High Sierra circa 2017, the earliest that Apple still supports.
A Macports build using a Portfile similar to the Gimp official one.
This issue does not affect builds on later versions of MacOS.
On a 12 year old computer, Apple does not support with a newer OS.
A temporary workaround is to compile with -Db_sanitize=address, which skips GIR step.
Suitable only for limited testing.
I don't understand the g-ir-scanner, why it is executing a library.
Anyway, looking at the Gimp code,
it seems like a call to gimp_unit_init is not made in a timely fashion.
That is what initializes the vtable.
I don't understand the code for "unit" either.
Probably not worth pursuing.