Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/20/2013 04:31 PM, Alexander Neundorf wrote:
The keywords won't interact well with PUBLIC/PRIVATE/INTERFACE keywords.
Let's assume there would be only PRIVATE, INTERFACE_BUILD and
INTERFACE_INSTALL.
I'll use PRIVATE for building the target.
I'll add INTERFACE_BUILD if I want to make using this target within the
project easier.
I'll add INTERFACE_INSTALL if I want to make using this target when installed
easier.
Am I correct so far ?
No. The keywords are:
* PUBLIC = use for me and my dependents
* PRIVATE = use for me but not my dependents
* INTERFACE = use for my dependents but not me
For PUBLIC and INTERFACE the my dependents is then split into
dependents using me from the build tree and dependents using
me from the install tree.
So e.g. I could do
tid(hello
PRIVATE ${Foo_INCLUDE_DIRS} ${Bar_INCLUDE_DIRS} ${CMAKE_SOURCE_DIR}/blub
INTERFACE_BUILD ${CMAKE_SOURCE_DIR}/blub ${Bar_INCLUDE_DIRS}
INTERFACE_INSTALL ${INCLUDE_INSTALL_DIR} ${Bar_INCLUDE_DIRS} )
In which way would this be problematic ?
list(APPEND somelist INTERFACE_INSTALL ${y} INTERFACE_BUILD ${x})
...
tid(hello INTERFACE_INSTALL ${somelist} ${INCLUDE_INSTALL_DIR})
The genex approach binds tightly so this does not happen.
The PUBLIC/PRIVATE/INTERFACE information belongs in the tid() call
so those keywords should not be in lists. The BUILD/INSTALL
information belongs with each (path/directory) value so the genex
binds tightly to it and can be in lists.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On Thursday 21 March 2013, Brad King wrote:
On 03/20/2013 04:31 PM, Alexander Neundorf wrote:
...
So e.g. I could do
tid(hello
PRIVATE ${Foo_INCLUDE_DIRS} ${Bar_INCLUDE_DIRS}
${CMAKE_SOURCE_DIR}/blub INTERFACE_BUILD ${CMAKE_SOURCE_DIR}/blub
${Bar_INCLUDE_DIRS}
INTERFACE_INSTALL ${INCLUDE_INSTALL_DIR} ${Bar_INCLUDE_DIRS} )
In which way would this be problematic ?
list(APPEND somelist INTERFACE_INSTALL ${y} INTERFACE_BUILD ${x})
...
tid(hello INTERFACE_INSTALL ${somelist} ${INCLUDE_INSTALL_DIR})
The genex approach binds tightly so this does not happen.
The PUBLIC/PRIVATE/INTERFACE information belongs in the tid() call
so those keywords should not be in lists. The BUILD/INSTALL
information belongs with each (path/directory) value so the genex
binds tightly to it and can be in lists.
Ok.
Still, is the PUBLIC part necessary ?
IMO PRIVATE and INTERFACE suffice, and for me it seems more straighforward to
separate only between these two.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/21/2013 02:47 PM, Alexander Neundorf wrote: Still, is the PUBLIC part necessary ? IMO PRIVATE and INTERFACE suffice, and for me it seems more straighforward to separate only between these two. PRIVATE and INTERFACE are sufficient but need to be duplicated to produce the equivalent of PUBLIC. It is very common for an implementation dependency to also be a usage requirement, especially for include paths. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On Thursday 21 March 2013, Brad King wrote: On 03/21/2013 02:47 PM, Alexander Neundorf wrote: Still, is the PUBLIC part necessary ? IMO PRIVATE and INTERFACE suffice, and for me it seems more straighforward to separate only between these two. PRIVATE and INTERFACE are sufficient but need to be duplicated to produce the equivalent of PUBLIC. It is very common for an implementation dependency to also be a usage requirement, especially for include paths. Yes, sounds ok. Still I would prefer the interface to be minimal and orthogonal. At least for me it is also easier to differentiate between use this when building foo and use this when using foo vs. the three options. When using this in a project, I'd want to keep my interface include dirs clean, i.e. as small as possible. With PUBLIC, PRIVATE and INTERFACE, directories can be added to the wrong one (i.e. PUBLIC instead PRIVATE or INTERFACE) and it will still build, but the interface will be bigger than necessary. With only PRIVATE and INTERFACE this can't happen. If you add it to the wrong one, it doesn't build. PUBLIC looks to me more like a convenience feature, but one which can be misused, and it's not strictly necessary. It may become the default choice for many, since it will be the easiest way to make some project compile. How about keeping PUBLIC out for 2.8.11 and adding it later on if it is really found to be missing ? This way is possible, removing later on is not. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [cmake-developers] CMake usage requirements in KDE Frameworks
On 03/21/2013 04:47 PM, Alexander Neundorf wrote: At least for me it is also easier to differentiate between use this when building foo and use this when using foo vs. the three options. Then don't use PUBLIC in your code. Others have the opposite view. When something does need to be in both interfaces there is room for typos and bugs if it must be duplicated. That's why tll()'s LINK_PUBLIC/LINK_PRIVATE signature was added. Before that one had to populate LINK_INTERFACE_LIBRARIES separately. Often a new public library would be added to tll() and left out of LINK_INTERFACE_LIBRARIES accidentally. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
