frameworks branch now requires CMake 2.8.6 RC 2

[Alexander Neundorf]

On Saturday, September 17, 2011 07:53:44 PM Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday, September 04, 2011 10:17:31 PM Stephen Kelly wrote:
> >> Stephen Kelly wrote:
> >> > With these features it is possible to build individual kde frameworks
> >> > standalone. I can now cmakekde in itemmodels or in tier1 (because the
> >> > tier1 libraries do not have dependencies on each other).
> >> > 
> >> > Please review the ECMQtFramework.cmake file which makes this possible.
> >> 
> >> Something else I forgot to mention in my previous mail: By porting to
> >> extra- cmake-modules, away from the macros that are already in kdelibs
> >> (kde4_add_library) I dropped some features. We need to consider those
> >> features and answer the questions:
> >> 
> >> * Is it still needed?
> >> * Should it be in ecm?
> >> * Should it be in cmake?
> >> 
> >> kde4_add_library handles automoc, rpath, export symbols, enable_final,
> >> and it sets the LINK_INTERFACE_LIBRARIES to empty.
> >> 
> >> With cmake 2.8.6, that macros automoc and exports handling are obsolete.
> >> I added some rpath handling to ecm in ECMQtFramework.
> >> 
> >> That leaves enable_final and setting LINK_INTERFACE_LIBRARIES to empty.
> >> I'm
> > 
> > Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
> > By default, all libraries a target is linked agaonst are in the
> > LINK_INTERFACE, which leads to unnecessary dependencies and increased
> > load time.
> > The alternative would be not to set it to empty, and expect our
> > developers to take care of it. I think this is not realistic.
> > So I'm quite sure we still want that
> 
> Ok. So should we set it even if nothing we link to should be excluded from
> the link interface?

You mean "should we set it empty even..." ?

Yes. IMO this needs to be default, because otherwise many developers will 
simply forget to reduce the link interface. This will make it compile and link 
for everybody, and probably only the packagers will notice the too-big link 
interface, and send patches quite late in the process.
This is how we got aware of the issue initially.
With two a too-small link interface, we get link errors, this is earlier in 
the process and that's why better.

> Should libraries somehow notify consumers of what they
> depend on? Is that what we need to use the Foo_LIBRARIES variable for?

Sorry, I don't really understand your question.

 
> I'd like if it was possible to write code like this without uncommenting:
> 
> target_link_libraries(some_executable ${itemmodels_LIBRARY}
> #   ${QT_QTCORE_LIBRARIES} ${QT_QTGUI_LIBRARIES}
> )

The correct way is:

target_link_libraries(some_executable ${itemmodels_LIBRARIES} )

The _LIBRARIES variable needs to contain everything you need to link against 
when using itemmodels.

When itemmodels is installed as exported target, the imported itemmodel 
library target has all libraries which have been listed as LINK_INTERFACE in 
its link interface.
I.e.

if you did 

target_link_libraries(itemmodels
      LINK_INTERFACE_LIBRARIES
        ${QT_QTCORE_LIBRARY}
       ${QT_QTGUI_LIBRARY} )

and export this target, then there is

add_library(itemmodels IMPORTED)

in the exports-file, and if the Config.cmake file then does

set(itemmodels_LIBRARIES itemmodels)

and you do later on 

target_link_libraries(some_executable ${itemmodels_LIBRARIES} )

this will link against the itemmodels library itself, and also QtCore and 
QtGui.

 
Does that answer your questions ?

Alex