Alle martedì 12 maggio 2009, Christophe Giboudeaux ha scritto: > 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...
Being incoherent with what was done with KDE CamelCase includes so far. > 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. Arguable. > 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. They all are KDE CamelCase includes. > 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. Unrelated. > 3/ The kdepimlibs camelcase headers will be available for the first time in > KDE 4.3. ... and? > 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). Ageed on the compatibility, and? > 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. Coherency with other modules? - all of KDE installs lowercase includes in $prefix/include, CamelCase ones in $prefix/include/KDE - kdepimlibs installs lowercase includes in $prefix/include, CamelCase ones in $prefix/include/KDEPimLibs See the asymmetry/incoherency? Which message to 3rd parties do we give with this? > 6/ Still for compatibility, we must keep KDEPIM_INCLUDE_DIR available until > KDE5. Unrelated to the choice. > 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. This is completely unrelated to choosing $prefix/include/KDE vs $prefix/include/KDEPimLibs for installing CamelCase includes. So, are there other serious reasons, other than that kdepimlibs "looks special(?)" wrt the rest of KDE? -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
