Bug 345484

Interresting patch.

If this one is applied to git, the other one bootstrap.local will differe. It's also dedicated to Linux.

Possible solutions : merge both or adjust bootstrap.local like bootstrap.linux.

Gilles Caulier

(In reply to Gilles Caulier from comment #1)
> Possible solutions : merge both or adjust bootstrap.local like
> bootstrap.linux.

Oh, I just understood why bootstrap.local exists. I think I will just merge it into bootstrap.linux utilizing a command line option, adapt README.LOCAL and leave bootstrap.local in place as a one line wrapper to prevent breaking anybodies workflow. OK?

yes it's ok. It's that i planed to do if time permit.

Note that i never user .local file. So please .linux workflow must be the default.

Gilles

Created attachment 91808 [details]
Patch for bootstrap.linux, bootstrap.local and README.LOCAL

Incorporated bootstrap.local into bootstrap.linux

I just left bootstrap.local as a wrapper for bootstrap.linux. Since bootstrap.local is designed to be edited in order to use it (no usable default directory) it may as well be removed completely. The functionality is now covered by bootstrap.local.

I already updated the references in README.LOCAL. However, this file still needs some love. I'm quite sure the procedure needs to be adapted to work with QT5. I will provide an update as soon as I figured out how to run a local installation complete with kio plugins.

The local is indeed used for local installations. The script could be changed to output a function/whatever method is nice to show how to launch the locally installed digikam. I'm not just sure what'd be the proper way for it.

Locally I have just this function to set the paths in my zshrc:
function digikam-kf5() {
    DIGIKAMROOT="/home/tpr/storage/kde/digikam-kf5-install"
    export KDESYCOCA=$DIGIKAMROOT/var/tmp/kde-tpr/ksycoca4
    export QT_PLUGIN_PATH=$DIGIKAMROOT/lib64/plugins:$QT_PLUGIN_PATH
    export KDE_FORK_SLAVES=1
    export XDG_DATA_DIRS=$DIGIKAMROOT/share:$XDG_DATA_DIRS
    export LD_LIBRARY_PATH=$DIGIKAMROOT/lib:$DIGIKAMROOT/lib64/
    export KDEDIRS=$DIGIKAMROOT
    export PATH=$DIGIKAMROOT/bin:$PATH
}

but similar could be just used to launch it directly... What do you think?

I orginally introduced bootstrap.local to be able to have several version of digiKam installed on my system. *However*, this is something that one should fully understand before doing it. Therefore, I believe that a typical user of digiKam shouldn't be able to perform such an installation, and that it should be kept for people knowing what they are doing, such as developpers or package maintainers. That means in particular not helping too much (for a local install). That being said, the reason behind a separate bootstrap file was to be able to run both bootstrap scripts without problem, and to clearly separate README files.

I like your solution of calling bootstrap.linux from bootstrap.local. This way, bootstrap.linux is not modified by the user (less issues when helping users), and only bootstrap.local has to be modified (and it's up to the user to figure out any issue he/she encounter). I'd keep it like that.

For bootstrap.linux, please remove CLEAN_ROOT from it, and any reference to it in the script, or at least, keep it in bootstrap.local. If DIGIKAM_INSTALL_PREFIX is /usr, we do not want anyone to be able to do a mess by setting it to 1! The DIGIKAM_INSTALL_PREFIX may also be removed since this is local stuff. Also, the ccache stuff has nothing to do with digiKam, so I'd remove it (if you need it, just put it in a custom boostrap.local). Same for ADDITIONAL_CMAKE_FLAGS: this does not apply for a typical linux install, and it can be included in a boostrap.local. In a nutshell, I'd put no configuration in bootstrap.linux, only in bootstrap.local. The reference to README.local in boostrap.linux is not useful either, only README is for this script. Some big warning in boostrap.local (that I should have put in the beggining) plus a reference to README.local would then suffice.

Teemu Rytilahti: I prefer the alias solution (see README.local) over your function. The reason is that once your function is executed, the current shell environment is modified until it is closed. The alias solution ensures that the environment is left untouched, such that "digikam" always start the binary on the system, as to opposed to the system or the local one depending on your function being executed or not in your case.

Thanks for your feedback, I will update the patch accordingly after next weekend since I'm AFK for a week.

Created attachment 92135 [details]
Updated patch for bootstrap.linux, bootstrap.local and README.LOCAL

After having a hard time figuring out how to run a locally installed KF5 application (short version: KDEDIRS is ignored and setting LD_LIBRARY_PATH is counterproductive now), I have updated README.LOCAL and bootstrap.local. Could anyone please test this on a virgin system? Running bootstrap.local and following the instructions should work out of the box.

I have also updated bootstrap.linux so it doesn't contain configuration anymore and doesn't mention bootstrap.local. A warning has been added to bootstrap.local.

Git commit 305d93516de0cf8cab0976200c0e1a420b826355 by Gilles Caulier.
Committed on 30/04/2015 at 06:15.
Pushed by cgilles into branch 'frameworks'.

apply patch #92135 from Ulf Rompe to support Eclispe IDE project at config time
FIXED-IN: 5.0.0

M  +8    -10   README.LOCAL
M  +43   -15   bootstrap.linux
M  +22   -57   bootstrap.local

http://commits.kde.org/scratch/mwiesweg/digikam-sc/305d93516de0cf8cab0976200c0e1a420b826355