On Tue, Jul 29, 2014 at 11:36 AM, "René J.V. Bertin" wrote: > 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.
The comment on the changeset includes a link to the ticket: - http://trac.macports.org/ticket/42872 But there are others: - http://trac.macports.org/ticket/41241 And the ticket alone lists 24 ports that added local patches to work around the problem. The problem probably affected *every single port* during an *upgrade* from an icompatible API change. > In fact, how can one get by NOT adding -I${prefix}/include and > -L${prefix}/lib, if prefix is not /usr or /usr/local ?? Mostly FindFoo.cmake. But ask the CMake developers. Usually the better question would be how to *remove* /opt/local, /sw and other prefixes when you have your ports installed under some nonstandard prefix or when you have both MP and HB installed for example. In any case adding -I${prefix}/include to CFLAGS will probably sooner or later bite you back, so think about using one of the other CMake variables. > Maybe I just don't have any of the ports that add options other than -I to > configure.cppflags, if those exist? CMake doesn't support cppflags. So if a port uses CMake and needs some extra flags, it would be useless for that Portfiles to add cppflags anyway. >> 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? You usually have to explicitly add something like -DAKONADI_CALENDAR_LIBRARY="${prefix}/lib/libakonadi-calendar.dylib" to the Portfile. See root6 for example. >> 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. Yes. > I'm not sure if CMAKE_INCLUDE_PATH is the one to go for though, and not > INCLUDEDIRS or something like that ... Maybe. I'm not sure which variable is the proper one. Mojca _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
