[KDE/Mac] compiling/installing

"René J.V. Bertin" rjvbertin at gmail.com
Tue Jul 29 06:54:45 PDT 2014


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

> The problem probably affected *every single port* during an *upgrade*
> from an icompatible API change.

I was only saying *I* didn't run into any issues that (with hindsight) must have been caused by the change.

> You usually have to explicitly add something like
> -DAKONADI_CALENDAR_LIBRARY="${prefix}/lib/libakonadi-calendar.dylib"
> to the Portfile. See root6 for example.

This all resolves around the question whether it's up to MacPorts to provide a global solution for (potential) ports that do not themselves contain the logic for looking under ${prefix}/include and ${prefix}/lib ?

>> 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.


Browsing through the cmake 3 docs (something you've surely been doing more than I), I see

> The convenience for installed targets is an INCLUDES DESTINATION component with theinstall(TARGETS) command:
> 
>> install(TARGETS foo bar bat EXPORT tgts ${dest_args}
>> 	INCLUDES DESTINATION include
>> )
>> install(EXPORT tgts ${other_args})
>> install(FILES ${headers} DESTINATION include)
> 
> This is equivalent to appending ${CMAKE_INSTALL_PREFIX}/include to the INTERFACE_INCLUDE_DIRECTORIES of each of the installed IMPORTED targets when generated by install(EXPORT).
> 
> When the INTERFACE_INCLUDE_DIRECTORIES of an imported target is consumed, the entries in the property are treated asSYSTEM include directories, as if they were listed in the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES of the dependency. This can result in omission of compiler warnings for headers found in those directories. This behavior for Imported Targets may be controlled with the NO_SYSTEM_FROM_IMPORTED target property.
> 
> If a binary target is linked transitively to a Mac OX framework, the Headers directory of the framework is also treated as a usage requirement. This has the same effect as passing the framework directory as an include directory.

But that's probably of more interest when writing cmake files.

> CMAKE_INCLUDE_PATH
> Path used for searching by FIND_FILE() and FIND_PATH().
> 
> Specifies a path which will be used both by FIND_FILE() and FIND_PATH(). Both commands will check each of the contained directories for the existence of the file which is currently searched. By default it is empty, it is intended to be set by the project. See also CMAKE_SYSTEM_INCLUDE_PATH, CMAKE_PREFIX_PATH.

and it seems my presumption about cmake taking a hint from the prefix path wasn't too far off:
> CMAKE_PREFIX_PATH
> Path used for searching by FIND_XXX(), with appropriate suffixes added.
> 
> Specifies a path which will be used by the FIND_XXX() commands. It contains the “base” directories, the FIND_XXX() commands append appropriate subdirectories to the base directories. So FIND_PROGRAM() adds /bin to each of the directories in the path, FIND_LIBRARY() appends /lib to each of the directories, and FIND_PATH() and FIND_FILE() append /include . By default it is empty, it is intended to be set by the project. See also CMAKE_SYSTEM_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, CMAKE_PROGRAM_PATH.


More information about the macports-users mailing list