Qt applications look for plugins in the paths specified by the QT_PLUGIN_PATH environment variable (additionally to a few built-in default locations). If you install to a different prefix, you are responsible for telling the system where to look for certain files.

The helper script prefix.sh created by kdesrc-build sets the following environment variables:
PATH, XDG_DATA_DIRS, XDG_CONFIG_DIRS, QT_PLUGIN_PATH, QML2_IMPORT_PATH, QT_QUICK_CONTROLS_STYLE_PATH

Not all of them are relevant for kmymoney (e.g. the last two) and PATH most likely already contains /usr/local/bin, but you will have to set the other ones if you expect kmymoney to work properly when installed outside of the standard location.

Ok. I was aware that this script existed, but I thought that it was part of the build environment.   It seems odd to me that after installing into a custom prefix that the software doesn't actually function without setting half a dozen environment variables.  It's not like the plugins are optional in any way, since it's not possible to open a data file without them.   In my experience software usually configures itself for the build path that it's installed into.

Have you considered installing a version of the prefix script (including an invocation of the kmymoney executable) as $CMAKE_INSTALL_PREFIX/bin/kmymoney ?     

Regardless, the advice is clear enough once you know what has to be done, so it's not a problem for me anymore, it just seems like an opportunity to make it easier for people to build kmymoney.

If someone wants to build and install kmymoney in lieu of a distro-supplied version, I'm pretty sure it "just works."  It's only if you modify any defaults that issues arise.  It might be reasonable to think that if you modify the build from the defaults, then you know what you are doing.  If you do alter the install prefix, then it might be specifically because you want it out of the way of standard system installed stuff.  Remember that much of where programs look for libraries already depends on environment variables, and is not fully built in to the executable, so it is not currently feasibly to adjust where a program looks for libraries and plugins.  

Also, none of that is specific to KMyMoney (as far as I know.)  I believe it all comes along for using the Qt/KDE/CMake environment and  build system.  I'm not even sure where such a wishlist would properly be directed.

In your case, it might be reasonable to create a script to source prefix.sh and then call the new kmymoney.  That is essentially how it is possible to have more than one version of the program installed at the same time, without them stepping all over each other.

I agree with most of what Jack said.  I was in fact trying to get a build that did not interfere with the distro-supplied version of KMyMoney, and I did "modify the build" from the defaults by specifying a non-standard installation prefix to accomplish that.  I agree that tracking multiple library versions and so forth can be complicated and often requires some careful thought.  Generally, I'm very cautious about building custom software and overwriting the installation in /usr as seems to be the default setting in the KMyMoney build.

I implemented a "workaround" to meet my needs, which installed the modified prefix script as /usr/local/bin/kmymoney, and the executable as /usr/local/bin/kmymoney.bin (as some other packages have done).   I just noticed that the debugging instructions suggest -DKDE_INSTALL_PREFIX_SCRIPT=ON, which curiously installs prefix.sh into /usr/local, but with permissions that only allow root to read the file, so it's not really a fix in my opinion.  It's possible that the behavior requiring a script that is NOT installed (or is installed with restrictive permissions) is fairly standard for KDE applications, and that my expected behavior is somehow made more difficult to implement by aspects of the standard KDE build environment that I'm not familiar with.  I am new to KMyMoney and KDE application development in general.  If the issue is "common", I too have no idea where to report it to.

I was simply remarking that the behavior of a custom prefix build of KMyMoney wasn't consistent with my usual experience with other Linux software.  Specifically, that building and installing software into /usr/local usually (in my experience) results in a working application without additional steps that you're supposed to "know".  I repeat that this is no longer a problem for me, and I'm only arguing this issue in hopes of presenting an easier "first build" experience for other possible developers.  It's not instantly obvious to a new developer why the plugins were not found and why the application does not work in the requested prefix.  If this is perceived as intentional or not-a-bug by the broader community, I'll let it go, use my workaround and move on, but I also see an opportunity to make things easier for new developers.  I'm willing to propose a change to implement the script installation, but only if the community perceives that the change is valuable (and so far it seems that they do not).

prefix.sh being installed for root only looks like a bug. This is probably caused by the assumption that nowadays people install into ~/.local (which is the default prefix used by kdesrc-build if I remember correctly) with their normal user instead of installing as root into something like /usr/local which requires root permissions.

One more thing: I just remembered that there is another script accompanying kdesrc-build: kdesrc-run. Those two scripts are meant to be used in combination. kdesrc-build to build and install an application and kdesrc-run to run it. So, in your case `kdesrc-run kmymoney` should run your self-built kmymoney with correctly setup environment.

Another thing to note is that kdesrc-build is primarily a tool for developers. It wasn't developed as tool for end users to simplify building, installing and running a KDE application. It can be used by end users who want to run the latest bleeding-edge development version of an application, but it's just not optimized for this. Having said this I expect merge requests which, optionally, make kdesrc-build install a wrapper similar to what you did to be considered for inclusion. https://invent.kde.org/sdk/kdesrc-build