https://bugs.kde.org/show_bug.cgi?id=345484Benjamin Girault <
[hidden email]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |
[hidden email]
--- Comment #7 from Benjamin Girault <
[hidden email]> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
