[KDE/Mac] compiling/installing

["René J.V. Bertin"]

On Jul 29, 2014, at 10:51, Mojca Miklavec wrote:

> You "reversed" the direction of the commit
Indeed ...

> (http://trac.macports.org/changeset/121112), but adding
> configure.cppflags is certainly not acceptable as it causes way too
> many headaches.

Really? How long had it been there (i.e. the previous cmake-1.0.tcl version), because I don't recall any issues that might have been caused by it.
In fact, how can one get by NOT adding -I${prefix}/include and -L${prefix}/lib, if prefix is not /usr or /usr/local ??

Maybe I just don't have any of the ports that add options other than -I to configure.cppflags, if those exist?

> Does it help if you add -DCMAKE_INCLUDE_PATH=${prefix}/include? (I'm
> not 100% sure if that's the right variable.)

I'd have to keep that in mind for when I run into a header search issue when building. I personally only had the issue with (-lakonadi-calendar) not finding libakonadi-calendar.dylib. And somehow I doubt cmake is clever enough to add -L/opt/local/lib if it encountered -I/opt/local/include?

> We were discussion replacing "cppflags=-I${prefix}/include" with a
> variable with a list of include paths. Then CMake or any other build
> system could convert that list into its own format.
> 
> For example
>    configure.includedirs-append ${prefix}/include/somelib
> could end up as
>    -DCMAKE_INCLUDE_PATH=${prefix}/include/somelib...
> in CMake and as something else in another system.

Yes, sounds like a plan, with something similar for LIBDIR I guess.
I'm not sure if CMAKE_INCLUDE_PATH is the one to go for though, and not INCLUDEDIRS or something like that ... but I might be mixing up with qmake. (I do recall fighting with either cmake or qmake to get it to take personalised include and/or library paths into account.)

R