C99 compatibility of internal setters

The folks package contains folks/redeclare-internal-api.h with this:

/* These functions are marked 'internal', which means Vala makes them ABI
 * but omits them from header files.
 *
 * We can't just tell valac to generate an "internal" VAPI and header
 * via -h and --internal-vapi, because the "internal" header redefines
 * things like "typedef struct _FolksPersonaStore FolksPersonaStore"
 * which are an error if redefined; so you can only include the "internal"
 * header or the "public" one, never both. If we use the "internal"
 * VAPI then libfolks-eds' "public" header ends up trying to include
 * the "internal" header of libfolks, which is unacceptable.
 *
 * Redundant declarations of functions and macros, unlike typedefs, are
 * allowed by C as long as they have identical content. We ought to be able
 * to check that these declarations match what Vala is currently generating
 * by including this header when compiling libfolks. Unfortunately,
 * if we do that we can't include <folks/folks.h>, because Vala-generated
 * C code redeclares local Vala-generated types, functions, etc. rather than
 * just including <folks/folks.h>, and then the typedefs conflict.
 */

void folks_persona_store_set_is_user_set_default (FolksPersonaStore* self,
    gboolean value);

This leads to a build failure on C99 compilers which do not implicit function declarations:

gcc -Ibackends/dummy/lib/libfolks-dummy.so.26.0.0.p -Ibackends/dummy/lib -I../backends/dummy/lib -Ifolks -I../folks -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gee-0.8 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -w -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -pthread -include config.h '-DBACKEND_NAME="dummy"' '-DG_LOG_DOMAIN="dummy"' -MD -MQ backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o -MF backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o.d -o backends/dummy/lib/libfolks-dummy.so.26.0.0.p/meson-generated_dummy-persona-store.c.o -c backends/dummy/lib/libfolks-dummy.so.26.0.0.p/dummy-persona-store.c
../backends/dummy/lib/dummy-persona-store.vala: In function ‘folks_dummy_persona_store_update_is_user_set_default’:
../backends/dummy/lib/dummy-persona-store.vala:998:2: error: implicit declaration of function ‘folks_persona_store_set_is_user_set_default’
  998 |       this.is_user_set_default = is_user_set_default;
      |  ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is this a Vala compiler problem? Is there a way to include folks/redeclare-internal-api.h from the generated C sources, so that the declaration is available?

1 Like

It’s a known issue in Vala: valac does not respect internal header/vapi setting (#358) · Issues · GNOME / vala · GitLab

Ideally we’d have a separate source/header file per .vala file (see Create a dedicated header per source file (#941) · Issues · GNOME / vala · GitLab ) but that’s also not implemented

1 Like

Thanks. Is there a way at least to add the declaration to the generated C sources, as a hack?

No idea, I’m afraid…