@oxalica Thanks for submitting this.

Although I'd like some more documentation on why this is needed. What does the config.h.in file look like? Why does exec_prefix need to be replaced with the path to the fcitx derivation?

Also, is there any way to report this upstream so they can make it easier for us (instead of us having to manually edit the config.h.in files)?

What does fcitx-remote -r do, and why does fcitx-remote need to call it?

@cdepillabout

Part of config.h.in,

#define VERSION_STRING_FULL "@VERSION_STRING_FULL@"
#define DATADIR "@datadir@"
#define LOCALEDIR "@localedir@"
#define EXEC_PREFIX "@exec_prefix@"
#define PACKAGE "@FCITX4_PACKAGE_NAME@"
#define LIBLOCALEDIR "@liblocaledir@"
#define ISO_CODES_PREFIX "@ISO_CODES_PREFIX@"
#define GETTEXT_PACKAGE "fcitx-configtool"
#define FCITX4_MAJOR_VERSION @FCITX4_MAJOR_VERSION@
#define FCITX4_MINOR_VERSION @FCITX4_MINOR_VERSION@
#define FCITX4_PATCH_VERSION @FCITX4_PATCH_VERSION@
// ...

And CMakeLists.txt fills the placeholders, make them relative paths to $out.

set(datadir ${CMAKE_INSTALL_PREFIX}/share)
set(localedir ${CMAKE_INSTALL_PREFIX}/share/locale)
set(exec_prefix "${CMAKE_INSTALL_PREFIX}")
set(liblocaledir ${CMAKE_INSTALL_PREFIX}/lib/locale)

configure_file(config.h.in config.h)

But it will run EXEC_PREFIX "/bin/fcitx-remote" in run-time, which belongs to fcitx, to let it reload the config.

Is it better to patch the line set(exec_prefix "${CMAKE_INSTALL_PREFIX}") of CMakeLists.txt?

@oxalica Thanks for this explanation.

Just to make sure I understand this:

• fcitx-configtool needs to call fcitx-remote during runtime.
• The cmake stuff for fcitx-configtool assumes that fcitx-remote and fcitx-configtool will both exist in the same bin/ directory?
• In nixpkgs, fcitx-configtool and fcitx-remote exist in different packages, so the config.h.in file needs to updated?

Here's a couple thoughts:

• Could you send a PR upstream (or open an issue), letting them know that the assumption that fcitx-configtool and fcitx-remote exist in the same directory is not a good assumption to make, and we would like more fine-tuned control to tell fcitx-configtool where fcitx-remote exists?
• It seems slightly dangerous to overwrite exec_prefix, since I imagine there could be some code in fcitx-configtool that looks for fcitx-configtool (or similar binaries) at exec_prefix.

I'd be fine merging this in given the following conditions:

• You send an issue/PR upstream explaining our situation.
• You link to the fcitx issue/PR in a comment in the derivation.
• You add a big warning/explanation in a comment for what is going on and why exec_prefix needs to be replaced. Really just something similar to fcitx-configtool: patch paths to fcitx-remote #73272 (comment). When someone new comes along and takes a look at this fcitx-configtool derivation, I want it to be immediately obvious why exec_prefix is getting re-written.

@cdepillabout
The repo is here. I've opened an issue fcitx/fcitx-configtool#17 but the repo seems no longer maintained. Sad.

I have another idea to replace only occurs of EXEC_PREFIX "/bin/fcitx-remote" (in gtk{3,}/config_widget.c) to have less surprise.

What's your opinion?

I've opened an issue fcitx/fcitx-configtool#17 but the repo seems no longer maintained. Sad.

Thanks! It is unfortunate that it is no longer maintained.

I have another idea to replace only occurs of EXEC_PREFIX "/bin/fcitx-remote" (in gtk{3,}/config_widget.c) to have less surprise.

I think that would be the safer option. If you can make this change I will merge in this PR.

@cdepillabout Fixed.

Thanks!