https://bugs.kde.org/show_bug.cgi?id=471061
--- Comment #4 from Cory F Cohen <cfcohe...@gmail.com> --- 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). -- You are receiving this mail because: You are watching all bug changes.
