headers installation and compilation tests

[Alexander Neundorf]

On Thursday 09 December 2010, David Faure wrote:
> > On Monday 29 November 2010, David Faure wrote:
> > > On Monday 09 August 2010, Volker Krause wrote:
> > > > 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.
>
> On Sunday 05 December 2010, Alexander Neundorf wrote:
> > MacroHeaderCompilationTest.cmake:
> > * it doesn't have docs at the top
>
> Sure, was waiting for input first. Added now.
>
> > * does it have to use kde4_add_executable() ? This adds mainly automoc,
> > and some RPATH settings. I think add_executable() should work too.
>
> Fixed.
>
> > * the name is too generic, since it tests something very special (can
> > header files be compiled if certain Qt macros are set)
>
> Well it also tests that the headers actually compile. Think of pure
> interfaces for instance: nothing in kdelibs compiles them, so a syntax
> error wouldn't be detected while compiling kdelibs; this test would detect
> it.
> This is really "test compiling these headers", so
> macro_header_compilation_test doesn't seem that far off to me. Any better
> suggestion, otherwise?

From the current name I would not guess that this macro checks whether some 
headers can be compiled with some specific Qt macros set.
I think "Qt" (or "KDE") should be in the name of the macro.
Maybe the macro should go into KDE4Macros.cmake and get the "KDE4_" prefix, 
maybe KDE4_CHECK_HEADER_COMPILES_WITH_QT_SETTINGS() or something like this.

> > * should this macro be installed ?
>
> Volker replied yes, so I added it now.
>
> > * why is the header_compile.cpp not rewritten everytime ?
>
> To speed things up.
>
> > Hmm, I guess the test is rebuilt everytime cmake runs, right ?
> > file(WRITE/APPEND ...) directly write the file, so its date changes.
>
> Yes.
>
> > 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.
>
> Sounds complicated, compared to the next solution (well, I guess?)


No(did not test, some CMAKE_CURRENT_BINARY_DIRECTORY etc. may be missing, 
etc.):

file(WRITE main.cpp.in "int main() ....")
file(APPEND main.cpp.in "blah blah")
configure_file(main.cpp.in main.cpp COPYONLY)

add_executable(foo main.cpp ...)
...


> > 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.
>
> Sounds good but I have no idea how to do that. Can you do it, or tell me
> how with more details?

I have not actually tried this yet myself for a Qt or KDE project.
I think it might not be trivial to do, but it seems to be the right thing to 
do.
In CMake sources, in Tests/CMakeLists.txt there is a macro add_test_macro() at 
the top, which does that for simple test projects.
We would have to make sure that these test projects use/find the same Qt as 
the calling project is using etc.
I'm not sure I'll have time to look at this before christmas, and then I'm for 
two weeks on vacation.

Alex