KArchive for Qt4

[Alexander Neundorf]

On Saturday 17 November 2012, David Faure wrote:
> On Thursday 15 November 2012 21:53:19 Alexander Neundorf wrote:
> > On Thursday 15 November 2012, Alexander Neundorf wrote:
> > > On Thursday 15 November 2012, David Faure wrote:
> > > > After my presentation on KDE Frameworks at the Dev Days, the obvious
> > > > question "where do we download this from" came up -- especially for
> > > > KArchive.
> > > > 
> > > > So I took some time afterwards and prepared a self-contained
> > > > KArchive-for-qt4 release.
> > > > 
> > > > This pointed out some interesting issues, especially in the
> > > > cmakelists. I
> > > > removed the dependency on ECM, and as a result I saw many things for
> > > > which I thought "this should be in upstream cmake". Especially the
> > > > LIB_INSTALL_DIR stuff looks way too complicated to get right without
> > > > much
> > > > copy/paste...
> > 
> > What else beside that ?
> 
> Only that and the code below, which I suppose would also be solved by using
> GNUInstallDirs.cmake?
> 
> set(INSTALL_TARGETS_DEFAULT_ARGS  RUNTIME DESTINATION "${BIN_INSTALL_DIR}"
>                                   LIBRARY DESTINATION "${LIB_INSTALL_DIR}"
>                                   ARCHIVE DESTINATION "${LIB_INSTALL_DIR}"
> COMPONENT Devel )
> # on the Mac support an extra install directory for application bundles
> if(APPLE)
>   set(INSTALL_TARGETS_DEFAULT_ARGS  ${INSTALL_TARGETS_DEFAULT_ARGS}
>                                     BUNDLE DESTINATION
> "${BUNDLE_INSTALL_DIR}" )
> endif(APPLE)

If you have only one library in the project, simply do 
install(TARGETS ... RUNTIME DESTINATION "${BIN_INSTALL_DIR}"
                    LIBRARY DESTINATION "${LIB_INSTALL_DIR}"
                    ARCHIVE DESTINATION "${LIB_INSTALL_DIR}")

The  COMPONENT Devel is just some extra help to be able to split the package 
into separate components, and BUNDLE only applies on OSX, and I think only for 
application bundles, which a library is not.

...
> It is definitely not my intention to "kill ECM" -- and I disagree with the
> commit that you made after Sune's comments, in threadweaver.

Let's just see it as an example how it looks without any further help from e-
c-m.

> We have to balance "easy to use for app developers" with "easy to write for
> framework developers". Not using ECM macros means writing a LOT more
> boilerplate code, which means a lot more unmaintainable copy/paste between
> frameworks, and a lot more changes to get things wrong.

Yes, it is more code, more chances to get things wrong, but it is easier to 
read and easier to modify.

This is the commit:
http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=83f678267c79bb3a8bb7c05b2fb7052d20f5fb84

Going through the files, only threadweaver/CMakeLists.txt, 
threadwaever/threadweaverConfig.cmake.in and 
threadweaver/threadweaver_version.h.in add code.

Basically code is added for two things: version handling and creating a 
Config.cmake file.

The version-handling code is simple code, everybody who uses cmake can 
understand:

set(THREADWEAVER_VERSION_MAJOR 5)
set(THREADWEAVER_VERSION_MINOR 0)
set(THREADWEAVER_VERSION_PATCH 0)
set(THREADWEAVER_SOVERSION ${THREADWEAVER_VERSION_MAJOR} )
set(THREADWEAVER_VERSION_STRING "${THREADWEAVER_VERSION_MAJOR}.
         ${THREADWEAVER_VERSION_MINOR}.${THREADWEAVER_VERSION_PATCH}")

configure_file(threadweaver_version.h.in
               ${CMAKE_CURRENT_BINARY_DIR}/threadweaver_version.h)

write_basic_package_version_file("${CMAKE_CURRENT_BINARY_DIR}/threadweaverConfigVersion.cmake"
                                 VERSION ${THREADWEAVER_VERSION_STRING}
                                 COMPATIBILITY AnyNewerVersion )


Additionally the two generated files are installed.

This will be mostly the same everywhere.
If we can put the lines above in some way in some function, which still keeps 
it readable that would be nice. Something like

ecm_setup_version(5 0 0
            [SOVERSION x]
            PREFIX threadweaver
            VERSION_HEADER_FILE threadweaver_version.h
            PACKAGE_VERSION_FILE threadweaverConfigVersion.cmake )

What do you think ?


The code for creating a Config.cmake file is not trivial, but IMO also not 
boilerplate, and Stephen agreed in Berlin that this will have to be done 
individually be every project. This is the added threadweaverConfig.cmake.in 
and the call to configure_package_config_file() in the CMakeLists.txt.

The Config.cmake file may contain project-specific information, it must take 
care of finding dependencies, it may include macro-files, etc. Trying to wrap 
that in a macro will IMO not make it easier to work with.

Alex