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."
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
