fix: define prefs_changes_print outside of prefs_changes

[botantony]

This causes build failures on macOS runners in Homebrew, see: Homebrew/homebrew-core#268970 https://github.com/Homebrew/homebrew-core/actions/runs/22305120219/job/64538952484?pr=268970

I didn't run make format because it modified other unrelated files (guess they were not formatted before) but I assume this PR follow the style guides

[jubalh]

This causes build failures on macOS runners in Homebrew, see: Homebrew/homebrew-core#268970 https://github.com/Homebrew/homebrew-core/actions/runs/22305120219/job/64538952484?pr=268970

Where can I see the exact build failure?

[botantony]

In the linked workflow

To be more specific:

  clang -DHAVE_CONFIG_H -I. -I./src  -I/opt/homebrew/opt/readline/include   -I/opt/homebrew/opt/gpgme/include -I/opt/homebrew/opt/libassuan/include -I/opt/homebrew/opt/libgpg-error/include  -I/opt/homebrew/include -D_DARWIN_C_SOURCE -Wall -Wno-deprecated-declarations -std=gnu99 -ggdb3 -Qunused-arguments -pthread -I/opt/homebrew/Cellar/glib/2.86.4/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.86.4/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.47_1/include -I/opt/homebrew/Cellar/glib/2.86.4/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/ffi -I/opt/homebrew/Cellar/glib/2.86.4/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.86.4/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.47_1/include  -I/opt/homebrew/opt/sqlite/include   -I/opt/homebrew/opt/python@3.14/Frameworks/Python.framework/Versions/3.14/include/python3.14 -DTHEMES_PATH="\"/opt/homebrew/Cellar/profanity/0.16.0/share/profanity/themes\"" -DICONS_PATH="\"/opt/homebrew/Cellar/profanity/0.16.0/share/profanity/icons\"" -DGLOBAL_PYTHON_PLUGINS_PATH="\"/opt/homebrew/Cellar/profanity/0.16.0/share/profanity/plugins\"" -DGLOBAL_C_PLUGINS_PATH="\"/opt/homebrew/Cellar/profanity/0.16.0/lib/profanity/plugins\"" -I/opt/homebrew/Cellar/libotr/4.1.1/include -g -O2 -I/opt/homebrew/Cellar/libstrophe/0.14.0/include -DLIBXMPP_VERSION_MAJOR=0 -DLIBXMPP_VERSION_MINOR=14 -I/opt/homebrew/Cellar/openssl@3/3.6.1/include -I./src -I/opt/homebrew/Cellar/libotr/4.1.1/include -g -O2 -I/opt/homebrew/Cellar/libstrophe/0.14.0/include -DLIBXMPP_VERSION_MAJOR=0 -DLIBXMPP_VERSION_MINOR=14 -I/opt/homebrew/Cellar/openssl@3/3.6.1/include -c -o src/config/scripts.o src/config/scripts.c
  src/config/preferences.c:301:5: error: function definition is not allowed here
    301 |     {
        |     ^
  src/config/preferences.c:324:17: error: call to undeclared function 'prefs_changes_print'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    324 |                 prefs_changes_print(full_key, new_value, undef);
        |                 ^
  src/config/preferences.c:324:17: note: did you mean 'prefs_changes'?
  src/config/preferences.c:291:1: note: 'prefs_changes' declared here
    291 | prefs_changes(void)
        | ^
  src/config/preferences.c:333:17: error: call to undeclared function 'prefs_changes_print'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    333 |                 prefs_changes_print(full_key, new_value, old_value);
        |                 ^
  src/config/preferences.c:351:13: error: call to undeclared function 'prefs_changes_print'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    351 |             prefs_changes_print(full_key, undef, old_value);
        |             ^
  4 errors generated.

[jubalh]

Thank you!

We could change it since it's not a big deal. But I'm also not 100% agreeing on it.

Clang here complains that nested functions are not part of ISO C. We don't follow ISO C.
We actually use GNU extensions and specifically set this in:

• https://github.com/profanity-im/profanity/blob/master/configure.ac#L399
• https://github.com/profanity-im/profanity/blob/master/meson.build#L6

Shouldn't Clang respect that and not complain?

[jubalh]

Looks like not https://clang.llvm.org/docs/UsersManual.html#intentionally-unsupported-gcc-extensions :

clang does not support nested functions; this is a complex feature which is infrequently used, so it is unlikely to be implemented

CC: @sjaeckel

[sjaeckel]

clang does not support nested functions; this is a complex feature which is infrequently used, so it is unlikely to be implemented

This is a useful feature which is infrequently used, since clang doesn't have support for it.

I'd love to say: FU clang! Don't try to turn the reality around and justify not implementing a useful feature because it doesn't have usage, if you're the reason it doesn't get used.

But since it a) this isn't my project and b) I'm also somewhat concerned about compatibility to other compilers: let's remove it to make Clang happy and add to the statistics "but it's not used, so nobody cares if it's implemented".

[botantony]

Another problem with that is that it is not possible to use GCC on macOS as the build system always passes -Qunused-arguments Clang flag to the compiler:

profanity/meson.build

Lines 71 to 72 in 657de5f

	if platform == 'osx'
	add_project_arguments('-Qunused-arguments', language: 'c')

profanity/configure.ac

Lines 404 to 405 in 657de5f

	AS_IF([test "x$PLATFORM" = xosx],
	[AM_CFLAGS="$AM_CFLAGS -Qunused-arguments"])

[sjaeckel]

LGTM after my minor comment is addressed.

[jubalh]

Another problem with that is that it is not possible to use GCC on macOS as the build system always passes -Qunused-arguments Clang flag to the compiler:

This was done in 2016 by a contributor to fix the build under osx: 4ca6296. If this isn't needed (anymore) we are happy to remove it :)

[botantony]

I think this is okay to keep this for Clang users, but the check should depend on the compiler, not the OS

[jubalh]

Thanks for your contribution @botantony !

[jubalh]

I think this is okay to keep this for Clang users, but the check should depend on the compiler, not the OS

For meson done in: 2b650c8