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 > not sure either are still needed or wanted (this was also brought up at the > buildsystem BoF in BDS). > > Do we still need enable_final? Kind-of, but with automoc in cmake this is not possible anymore, because with enable-final only one file is handed to add_executable, and automoc does not work on files included in the source files. So, enable-final is one for now with automoc in cmake. But gcc supports inter-object optimizations since 4.5 or so, so the improved optimization is not lost. If enable-final is really seriously requested, it needs to be added to cmake, similar to how automoc has been added. Alex