headers installation and compilation tests

[Alexander Neundorf]

On Monday 29 November 2010, David Faure wrote:
> On Monday 09 August 2010, Volker Krause wrote:
> > On Saturday 07 August 2010 02:24:16 Aaron J. Seigo wrote:
> > > On August 6, 2010, Thiago Macieira wrote:
> > > > Side comment: shouldn't all of this (the includes and the
> > > > installation rules) be auto-generated?
> > >
> > > they should, but as you pointe out they aren't. the result is exctly
> > > what one would expect from a manual process: frequent ommissions,
> > > occassional
> > >
> > >  breakage.
> > >
> > > would be a nice little project for someone to work on :)
> >
> > Indeed. At least the install part is done automatically in
> > kdepimlibs/includes already, with the downside that it only picks up new
> > headers after a CMake re-run, but still much nicer than the explicit list
> > IMHO.
>
> I had a look at this, and it doesn't allow to have headers that are
> conditionnally installed -- unless they are in a separate subdir.
>
> So it creates a problem for things like
>
> if(QT_QTOPENGL_FOUND AND OPENGL_FOUND)
>    install(FILES
>      Plasma/GLApplet
>    DESTINATION ${INCLUDE_INSTALL_DIR}/KDE/Plasma COMPONENT Devel)
> endif(QT_QTOPENGL_FOUND AND OPENGL_FOUND)


Some important part must have been cut off at the top...
So this is about in some way automatically figuring out which headers to 
install ?

I'm against "magic" things happening, so the explicit listing of the header 
files definitely has its good sides.
Doing this via file(GLOB ...) is bad, since, as mentioned, this only happens 
at cmake time, and not automatically when it should.

> if(NOT KDE_NO_DEPRECATED)
>   install( FILES
>      Plasma/AnimationDriver
>   DESTINATION ${INCLUDE_INSTALL_DIR}/KDE/Plasma COMPONENT Devel)
> endif(NOT KDE_NO_DEPRECATED)
>
> and other "if not deprecated" and "if UNIX" tests.
> Moving such headers to separate subdirs sounds hackish, and totally breaks
> any hopes of autogenerating the forwarding headers.
>
> I think we should keep the current list of headers in kdelibs, or move to a
> completely automated system where we gather the public headers from each
> lib and generate forwarding headers, which would also make it possible to
> use <KFoo> in kdelibs, but I'm not sure it's worth the trouble.

Yes.

> > It also has a test that makes sure all headers compile with strict
> > flags (QT_NO_CAST_FROM_ASCII, etc), might be interesting for kdelibs as
> > well.
>
> Yep, very interesting, I just wrote the attached patch in order to check
> this in kdelibs - without using the forwarding headers though, since they
> don't compile in kdelibs before being installed.
> Instead I'm doing this per-library, using its already set up include
> directories and their list of installed headers. Attaching, for review on
> kde- buildsystem. Tested on kdeui and kio, works fine, needs to be applied
> to all other libs as well.


MacroHeaderCompilationTest.cmake:
* it doesn't have docs at the top
* does it have to use kde4_add_executable() ? This adds mainly automoc, and 
some RPATH settings. I think add_executable() should work too.#
* the name is too generic, since it tests something very special (can header 
files be compiled if certain Qt macros are set)
* should this macro be installed ?
* why is the header_compile.cpp not rewritten everytime ?
Hmm, I guess the test is rebuilt everytime cmake runs, right ?
file(WRITE/APPEND ...) directly write the file, so its date changes.
If you use configure_file(), it changes the target file only if its contents 
differ from the source file. So you could use the file() commands to generate 
the file, and then basically copy that file using configure_file(), so it 
will only have changed (and then be rebuilt) when the contents actually 
changed. 
Or, the test could consist of actually creating a tiny cmake project, which 
then builds the executable. I.e. header_compile.cpp would not be build at 
build time of kdelibs, but at "make test" time of kdelibs.
This is done a lot in the tests for cmake itself.

Alex