On Tuesday, 13 August 2013 08:30:54 CEST, Pali Rohár wrote:
I do not like idea to include compile output path into binaries. This sounds like that something is bad if some random path (=compile path) must be present in application executable.
I asked for opinion, I got one -- thanks. I happen to disagree with you, see below.
(Note that we already require embedding "ranodm paths" for l10n, cf. the $PKGDATADIR.)
Also there can be lot of other problems with this. If user move trojita source/build tree to another location it will break loading plugins of already compiled trojita binary.
When user moves any of these, it will break the cmake setup. Cmake will refuse to build when you move the source dir or the binary dir; that's a property of upstream cmake, not our setup.
And if somebody want to use trojita without install it into system (portable version), then it will not work too, if he move trojita binary to other directory/disk/mount point.
I'd say that `make install` serves this purpose, but I understand that such a setup is popular on Windows and as such should be supported in Trojita.
However, please note that what I suggested was simply the other way round -- if the binary the user is running is already installed, it will only load the plugins from the predefined location ($PREFIX/lib/trojita/trojita_plugin_*). The lookup in $APPDIR/trojita_plugin_* would still be used when the binary is not installed into the predefined path.
In short, the change I'm proposing is to explicitly skip $APPDIR if Trojita is already installed into $PREFIX/bin, i.e. if the runtime-detected qApp->applicationDir() matches the build-time $APPDIR, typically /usr/bin.
Does this answer your concerns, or do they still apply? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
