Hello David. Thank you for this important groundwork that g-golf is. Sorry to say, I have not developed any GUI and had no time as planned. It will not happen with me. But Debian is not the problem; all is fine there (unlike G-Golf on Guix on Debian).
I also failed to put a libg-golf-tests library to actually test gobject libraries in g-golf’s tests and link it with libtool, but it never worked, because autotools does not support linking for tests and all libtool executing would have to be done manually. The feedback I can give: guile-zlib in its build system autodetects the location of its needed libz library in configure.ac as LIBZ_LIBDIR, substitutes that in a config.scm.in module and calls (dynamic-link %libz) on that path. If you made g-golf/init.scm do this, it would be easy on Guix/Nix to build from source. David Pirotte <da...@altosw.be> writes: > As i did suggest already, you should ask for some guix highly > knowledgeable designer/developer (and who deeply knows the other > involved domains, C, guile's ffi implementation, dynamic libs linking > ...) - I'd happily stand corrected, and happily patch g-golf if ... but > till proved wrong, i don't think it is a g-golf problem. I’m missing an entry point to debug if the problem is <https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/main/girepository/gitypelib.c> and do not understand typelibs, except I see the giscanner part of gobject-introspection needed Nix-/Guix-specific patches: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/libraries/gobject-introspection/absolute_shlib_path.patch which I cannot understand at the moment. I suspect you’d need similar work. Then, I see on docs.gtk.org there is a girepository 3.0 (likely a typo and meant to say 2.0) migration which will make it hard to try the latest girepository version with g-golf, but also, no version of girepository 2.0 is packaged for guix anyway. It seems much movement is being done there under gobject-introspection’s hood. >> Intermittently I once saw a different error: >> ... > > I can't make sense of this error, but so you know, vfunc-checks checks > that the (upstream lib) virtual function you are trying to define in > g-golf exists in the class you are 'altering', and also checks that the > scheme virtual function name is correct [1] So indeed you regard it as unrelated, too. I tried but wasn’t able to make any reproducer, because the issue happened no longer; it did not happen in container isolation. But the problematic build, that I did not keep, was isolated. Could you document this purpose of vfunc-checks in g-golf/hl-api/vfunc.scm? Clearly you have put a lot of glib introspection knowledge in the g-golf implementation that an outsider would understand only with IRC help. But it’s the same for gobject-introspection itself. > So it disappeared and you can't reproduce it, let's concentrate on > the (g-golf) virtual function definition bug in Nix/Guix ... Yes, this is the only real annoyance. Regards, Florian
