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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
