> Hello, > > CMake support for kdelibs is almost done, but i still need some ideeas: > > 1) I'm not sure if is good ideea to commit cmake file into svn as is. But > otherwise we can't test/fix it, I think. Please commit them to SVN. Automake will still be there in parallel for quite some time. ;-) > > 2) I need some advices about which options must be ON/OFF by default. > Also, we > must to define very clear and in consistent way the names of variable > which > enable/disable various options. Have you run ./configure --help in kdelibs? That should give the names, descriptions, and default settings of all current configuration options. > > 3) We need to define in consistent way variable names for standard > directories > (for example now the "bin" directory is defined as "BIN_INSTALL_DIR"; > but "etc" directory is defined as "SYSCONFDIR" - inconsistent naming, > inherited from kde4 and autotools). I would leave it as-is for now for compatibility with other upstream projects such as Kaffeine. Should we desire to change this in the future an automated run with sed would do the trick. > > 4) I think we must drop support for some (very) obsolete thing, like > libalsa < > 0.9, hspell (now hebrew spelling support is incorporated in aspell too), > old/unused styles (like riscos). Also, anybody really using "fast malloc" > support? Let's save that for 3.5.14. You can remove the autodetection of these old version in CMake if you want to, but code has to remain as-is in the applicable source files for use by Automake. > > 5) KDE using plenty compiler flags. We really need to use all of them? > Maybe > is better ideea to pass cflags options to distro packagers and to keep > only > strictly necessary cflags. Yes! Trinity is all about configurability and letting the user decide what he or she wants to do with the software. ;-) > > 6) We need to cleanup a little the code. I found code which are not > compiled/installed at all (for example: [kate/plugins/autobookmarker], > [kdeprint/foomatic], [kdeprint/lpd], [khtml/java], etc). I don't doubt that. Shall we set another target for 3.5.14? > > 7) I need help for creating an external svn directory like [admin] for > common > cmake macros. As a beginner svn user, I have no ideea how to do it. OK, I can do that. As I am unfamiliar with CMake, I will need to know the directory name that will contain the shared CMake files (e.g. for automake the name is admin). > > 8) Must be completed/reviewed tests for cmake configure stage. configure.h > is > very large piece of code and is very dificult to made it by just one > person. For certain! There are individuals on this list who could undertake such testing. Personally as soon as CMake support is in SVN, I will switch the Debian and Ubuntu SVN nightly builds to use CMake for those modules instead of Automake. That will expand the number of testers significantly. > > 9) Some dependencies must be required, not optional. For example, bzip2, > jpeg > and openssl support, which in these days are available by default on most > current distros. I agree, especially since the CMake port is targeting those newer distributions. > > 10) We need to decide how various pieces of trinity will be detect each > another (for building). I'm for extensive using of pkgconfig mechanism, > which > seems standard for all modern distros. I succesfully used it for > tqtinterface > and arts. Sounds good to me. > > And many more little things... :) > > Just for remember, there are my work: > > http://www.thel.ro/trinity/kdelibs.html > http://github.com/serghei/kde-trinity-cmake > > > PS Sorry for my english, I will try to explain better if anybody do not > understand what I want to say :) > Your English is perfectly acceptable. ;-) Thank you once again for undertaking this large task! Tim