On Tuesday 12 May 2009 19:31:41 Andreas Pakulat wrote: > > As asked by Pino (just to make sure that this doesn't get lost as I've > discussed with him a bit different things): Why is this done at all? All > the headers in kdepimlibs are namespaced with the relevant libraries > inside prefix/include/KDE. So whats the reasoning? I don't see the old > version create problems for anyone, but apparently all applications that > used the old dir need to be built from scratch so cmake find the right > include dirs (and doesn't use the cache). >
Well, I don't see any problem created by the new prefix... Several thoughts then : 1/ When looking at my current /usr/include/KDE, it looks like a giant blob where all kinds of headers from every module (seems to) live happily. I wouldn't call that a generic dir but the inheritance for the KDE3 behaviour. I don't really understand how logical it would be to have the pimlibs headers in the same directory as (eg) KZip, OrgKdeKDirNotifyInterface or ThumbCreator. 2/ The cmake introduction in the build system (and specially since cmake > 2.6.0) made installation in random prefixes quite easy and the KDE modules are much more modular. 3/ The kdepimlibs camelcase headers will be available for the first time in KDE 4.3. 4/ The consequence of 3: for compatibility reasons, we won't be able to change this directory after 4.3 if we go for /KDE (which should, imo, be reserved for the KDE core headers, ie KDELibs). 5/ Considering 1,2 and 3, I still didn't read any valid reason for using the same prefix as kdelibs, kdebase, kdegames etc... and add more files inside /KDE. 6/ Still for compatibility, we must keep KDEPIM_INCLUDE_DIR available until KDE5. The consequence of 2 and 6 is that, even after 3 monthes, some projects still wrongly use KDEPIMLIBS_INCLUDE_DIR where they need KDEPIMLIBS_INCLUDE_DIRS. That just simply breaks the compilation for whoever doesn't install kdepimlibs in the same prefix as kdelibs. I absolutely want to avoid such problems in the future. Christophe.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
