headers installation and compilation tests

[Volker Krause]

On Sunday 05 December 2010 15:21:26 Alexander Neundorf wrote:
> 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 ?

yes, I'd like to use it in kdepimlibs as well :)

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20101206/6cae13a3/attachment.sig