KDE/kdelibs/cmake/modules

[Kevin Ottens]

On Tuesday 1 September 2009 21:29:31 Alexander Neundorf wrote:
> On Wednesday 26 August 2009, Kevin Ottens wrote:
> > SVN commit 1015825 by ervin:
> >
> > OK, my previous claim for r1015454 was wrong. The new behavior breaks
> > old file in many more cases.
> 
> Why do we need this option ? Are there otherwise name collisions ?

In this particular case no collision. It's just to achieve some consistency in 
the includes between the build time and once installed. Once installed the 
generated file end up in a core subdir. So third party can do:
#include <.../core/settings.h>
I just find it confusing that from within the project I have to make my 
includes differently:
#include ".../settings.h"

Then my consistency OCD triggers and I end up patching our CMake macros to 
ease my pain. :-)

Now what I was commenting is that, in the past I *had* collisions for a 
similar case (although it was about moc files back then). I ended up renaming 
quite a lot of files... really painful. I think a similar approach than what I 
did for kcfg could be applied for the moc files (and ui files obviously).

> > So activating the new behavior only if the
> > USE_RELATIVE_PATH option is given.
> 
> Please document USE_RELATIVE_PATH at the top of FindKDE4Internal.cmake.

OK, done (r1019060).

> Can you please check whether you can use if(IS_ABSOLUTE) and
> file(RELATIVE_PATH) to make the logic easier to understand ?

Hm, right now I don't have the module where I was testing the behavior of this 
script, so I'm a bit uneasy about modifying it. Could I get more details on 
the change you'd foresee? or point me in the right direction for the macros 
you propose me to use?

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090902/b72816ae/attachment.sig