digikam 4.3.0 (was: depends_build on minimal version?)

[Mojca Miklavec]

On Sat, Sep 20, 2014 at 9:52 AM, René J.V. wrote:
> On Friday September 19 2014 19:42:06 Lawrence Velázquez wrote:
>
>>> No ... it was easier to just remove the offending include directory ...
>>
>>That's an unacceptable solution. If a user interrupts the build, that directory might never be put back where it belongs, and they'll have no idea how it happened.
>>
>>Just figure out how to add the correct directories to the header search path.
>
>
> I wasn't proposing this as a solution for the portfile. I have reported the issue upstream, but so far the only reply I have got (from the official port maintainer) boils down to "works for me". At the same time this person didn't know MacPort provides binary packages, so I'm not 100% sure that testing was done properly. You wouldn't run into this issue installing digikam anew, for instance, instead of upgrading an existing install.
>
> I'd love to figure out exactly what happens, but I'd need a hand from a seasoned cmake user for that. I find the syntax very unhelpful and it's not like this is a small and easy project to jump in and learn while doing.

I'm somewhat following this thread, but I miss more detailed
information about the problem (without having to spend a few hours
figuring out which version to install, what files to check, how to fix
things, ...). To start with it complains about something I'm not
familiar with: "Can't install libiodbc because conflicting ports are
active: unixODBC"

I'm almost sure that this is a common & well-known underlying problem
though. I first came across it in
https://its.cern.ch/jira/browse/CLHEP-101

(Ending with "Please consider dropping MacPorts in favor of homebrew,
which is at least easier to deal with. Many people have dropped
MacPorts because of problems such as the ones you are having.")

The autotools/configure-based installations of almost anything would
require setting something like
    CPPFLAGS=-I/opt/local/include
to find the header files and then the code would be compiled with something like
    $(CC) -I./ -I/opt/local/include [...]
which would make sure that the local/newer copy of the header would be
found before the already installed header.

On the contrary this is all very very confusing in CMake. And if you
happen to add -I/opt/local/include to CFLAGS, you will almost always
end up with
    $(CC) -I/opt/local/include -I./ [...]
and having an older version of the (incompatible) headers installed
will almost always break compilation.

Se also https://trac.macports.org/ticket/42872

A few things that seem a bit strange in the digikam's Portfile are the
following:

-DCMAKE_SYSTEM_PREFIX_PATH=\"${prefix}\;/usr\" \
-DCMAKE_MODULE_PATH=\"${prefix}/share/cmake-2.8/Modules\;${prefix}/share/cmake/modules\"
\
-DCMAKE_PREFIX_PATH=\"${prefix}/lib/cmake\" \

The second line is wrong anyway. In particular we no longer ship CMake
2.8, but 3.0. The rest is (in my opinion) something that either the
PortGroup should set or shouldn't (need to) be set at all.

One thing that I hate about CMake in particular is the need to specify
each and every dependency in the following way:
   configure.args-append
-DMYSQL_CONFIG_EXECUTABLE=${prefix}"/lib/mysql55/bin/mysql_config"
   configure.args-append
-DPOSTGRESQL_INCLUDE_DIR="${prefix}/include/postgresql92" \
       -DPOSTGRESQL_LIBRARIES="${prefix}/lib/postgresql92/libpq.dylib"
other workarounds and shortcuts failed to work for me so far.

Mojca