digikam 4.3.0 (was: depends_build on minimal version?)

[René J.V. Bertin]

Hi Ian,

On Friday September 19 2014 09:20:10 Ian Wadham wrote:

> I don't know why Ruby should be required here. AFAIK KDE apps
> do not use Ruby and PO (translation) files come in via some (dynamic?)
> KDE route. Could there be a spurious dependency here?

Turns out it's all about nothing. The ruby script is for fetching a fresh (and more complete?) copy of the docbook and PO files from the KDE servers. At first it seemed this was an obligatory step to get cmake to accept building the translations, but after insisting a bit it turned out that the whole step was unnecessary.

Fortunately, because I would have hated having to install a specific version of script language (and patch the cmake file to avoid having to port select that version...)

Now there is another thing with this new digikam version. I comes with a newer copy of libkgeomap. The cmake system is supposed to add the path to the included header files to the compiler options, but apparently the script finds the headers from the previous, 4.0.0 version that were installed in /opt/local/include/libkgeomap . At least, the command line for the files that failed to compile didn't have the -I pointer to the included header directory. This was with clang++-mp-3.4 . What would be the best way to prevent this from the Portfile? Delete or move aside /opt/local/include/libkgeomap in pre-configure and then move it back in post-build or post-destroot (if it was moved aside)? Deactivate the (or all) previous versions, if that's possible? Detect the situation and bail out with a message to the user?

R.