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

69 lines
2.6 KiB
Meson
Raw Normal View History

libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
# XXX: we have a bunch of (manually run?) tests inside libgimp/test/.
# These should either be deleted or transformed into real unit tests.
meson: share a same environment for all usages of self-built GIMP In particular GIMP used for unit-testing, or in other cases as a build tool, from the non-installed binaries, can use a same meson `env` object.
2024-04-05 21:35:59 +08:00
if not meson.can_run_host_binaries()
warning('libgimp unit testing disabled in cross-building or similar environments.')
subdir_done()
endif
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
tests = [
libgimp, libgimpcolor: make real unit test of old (compiled but unused) … … test-color-parser.c file. The file libgimpcolor/test-color-parser.c was compiled but never actually called by the build. Now that we have a nice infrastructure to test libgimp API, I am moving it there with the new format. Doing this also allowed me to discover some bugs in CSS parsing, as well as discover Python binding was failing here (cf. the few previous commits). Only one test is disabled so far, the one where 4 digits are used per channel in hexadecimal notation: "#64649595eded". This format simply doesn't appear anywhere in the spec, and also the result values in the samples listing don't even fit. So far, I'm just unsure what to do with it, if we want to keep this support (of some kind of higher precision hex notation, but not specified, so is it even used by anyone?) or not. All the other tests just work in both C and Python!
2024-04-20 18:39:52 +08:00
'color-parser',
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
'export-options',
libgimp: new unit tests around GimpImage and item API. Right now, it only tests a few API, such as creating an image, then a text layer, then inserting it in the image. This is a test to avoid regression bug after having fixed #9923 in a previous commit.
2024-08-02 20:12:10 +08:00
'image',
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
'palette',
libgimp: new unit tests for GimpUnit.
2024-08-02 18:12:39 +08:00
'selection-float',
'unit',
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
]
meson: share a same environment for all usages of self-built GIMP In particular GIMP used for unit-testing, or in other cases as a build tool, from the non-installed binaries, can use a same meson `env` object.
2024-04-05 21:35:59 +08:00
# Unit testing environment is based on gimp_run_env with additional environment
libgimp: library unit testing should use a separate environment. The comment I had written back then was wrong. Meson in fact can create an env object from another with a simple assignment (which copies the object, rather than pointing to a same object), per the answer which has been given to me in: https://github.com/mesonbuild/meson/issues/13045 This allows to have a properly separate environment (when using GIMP as a build tool, we don't want to load the test files).
2024-04-18 05:56:11 +08:00
# variables and added temporary test plug-ins. Assignment is a deep copy, so
# test_env here is a new object.
meson: share a same environment for all usages of self-built GIMP In particular GIMP used for unit-testing, or in other cases as a build tool, from the non-installed binaries, can use a same meson `env` object.
2024-04-05 21:35:59 +08:00
# See: https://github.com/mesonbuild/meson/issues/13045
libgimp: library unit testing should use a separate environment. The comment I had written back then was wrong. Meson in fact can create an env object from another with a simple assignment (which copies the object, rather than pointing to a same object), per the answer which has been given to me in: https://github.com/mesonbuild/meson/issues/13045 This allows to have a properly separate environment (when using GIMP as a build tool, we don't want to load the test files).
2024-04-18 05:56:11 +08:00
test_env=gimp_run_env
test_env.append('GIMP_TESTING_PLUGINDIRS', meson.project_build_root() / 'libgimp/tests/c-tests/')
test_env.set('GIMP_TESTING_ABS_TOP_SRCDIR', meson.project_source_root())
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
run_python_test = find_program('./libgimp-run-python-test.sh')
libgimp: add C tests to the libgimp testing infrastructure. Most of the C boiler-plate code is generated so that all you have to do is implement the run() function with test code in it. Also adding a README to make it all very clear and easy to add new tests.
2024-02-29 23:16:52 +08:00
run_c_test = find_program('./libgimp-run-c-test.sh')
cat = find_program('cat')
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
foreach test_name : tests
basename = 'test-' + test_name
libgimp: add C tests to the libgimp testing infrastructure. Most of the C boiler-plate code is generated so that all you have to do is implement the run() function with test code in it. Also adding a README to make it all very clear and easy to add new tests.
2024-02-29 23:16:52 +08:00
py_test = meson.current_source_dir() / basename + '.py'
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
test(test_name, run_python_test,
meson: on macOS temporarily update rpath to find libraries of non-installed GIMP. The DYLD_LIBRARY_PATH trick was working fine on CI, but not on local builds for Lukas. Apparently there are security measures disabling the environment variable. Instead let's temporarily add then remove libgimp libraries folders from rpath. See: https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/merge_requests/292#note_2075291
2024-04-09 03:29:19 +08:00
args: [ gimp_exe.full_path(), py_test ],
libgimp: library unit testing should use a separate environment. The comment I had written back then was wrong. Meson in fact can create an env object from another with a simple assignment (which copies the object, rather than pointing to a same object), per the answer which has been given to me in: https://github.com/mesonbuild/meson/issues/13045 This allows to have a properly separate environment (when using GIMP as a build tool, we don't want to load the test files).
2024-04-18 05:56:11 +08:00
env: test_env,
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
suite: ['libgimp', 'python3'],
timeout: 60)
libgimp: add C tests to the libgimp testing infrastructure. Most of the C boiler-plate code is generated so that all you have to do is implement the run() function with test code in it. Also adding a README to make it all very clear and easy to add new tests.
2024-02-29 23:16:52 +08:00
c_test_name = basename + '.c'
c_test = custom_target(c_test_name,
input: [ 'c-test-header.c', c_test_name ],
output: c_test_name,
command: [cat, '@INPUT@'],
capture: true,
install: false)
c_test_exe = executable(basename,
c_test,
dependencies: [ libgimp_dep, pango ],
install: false)
# Same ugly trick as in plug-ins/common/meson.build to detect plug-ins in a
# non-installed build directory.
custom_target(basename + '.dummy',
input: [ c_test_exe ],
output: [ basename + '.dummy' ],
command: [ python, meson.project_source_root() / '.gitlab/cp-plug-in-subfolder.py',
c_test_exe, meson.current_build_dir() / 'c-tests' / basename,
'@OUTPUT@' ],
build_by_default: true,
install: false)
meson: on macOS temporarily update rpath to find libraries of non-installed GIMP. The DYLD_LIBRARY_PATH trick was working fine on CI, but not on local builds for Lukas. Apparently there are security measures disabling the environment variable. Instead let's temporarily add then remove libgimp libraries folders from rpath. See: https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/merge_requests/292#note_2075291
2024-04-09 03:29:19 +08:00
plugin_executables += [meson.current_build_dir() / 'c-tests' / basename / fs.name(c_test_exe.full_path())]
libgimp: add C tests to the libgimp testing infrastructure. Most of the C boiler-plate code is generated so that all you have to do is implement the run() function with test code in it. Also adding a README to make it all very clear and easy to add new tests.
2024-02-29 23:16:52 +08:00
test(test_name, run_c_test,
meson: on macOS temporarily update rpath to find libraries of non-installed GIMP. The DYLD_LIBRARY_PATH trick was working fine on CI, but not on local builds for Lukas. Apparently there are security measures disabling the environment variable. Instead let's temporarily add then remove libgimp libraries folders from rpath. See: https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/merge_requests/292#note_2075291
2024-04-09 03:29:19 +08:00
args: [ gimp_exe.full_path(), meson.current_source_dir() / c_test_name, basename ],
libgimp: library unit testing should use a separate environment. The comment I had written back then was wrong. Meson in fact can create an env object from another with a simple assignment (which copies the object, rather than pointing to a same object), per the answer which has been given to me in: https://github.com/mesonbuild/meson/issues/13045 This allows to have a properly separate environment (when using GIMP as a build tool, we don't want to load the test files).
2024-04-18 05:56:11 +08:00
env: test_env,
libgimp: add C tests to the libgimp testing infrastructure. Most of the C boiler-plate code is generated so that all you have to do is implement the run() function with test code in it. Also adding a README to make it all very clear and easy to add new tests.
2024-02-29 23:16:52 +08:00
suite: ['libgimp', 'C'],
timeout: 60)
libgimp: new unit testing framework for libgimp. With Python binding, it gets very easy to test new functions. I've been wondering if we need C counterparts, but really since it's a GObject Introspection binding, if a function succeeds there, it should also succeed in C code. For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test both the direct C binding and PDB procedure since in some cases, one or the other may not properly working. See #10885.
2024-02-29 05:27:28 +08:00
endforeach