5 Oct
2010
5 Oct
'10
4:21 a.m.
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