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