4 Oct
2010
4 Oct
'10
10:12 p.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.
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.
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).
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?
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.
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).
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.
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.
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.
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.
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 :)
--
Serghei
5 Oct
5 Oct
4:21 a.m.
New subject: [trinity-devel] cmake build system - need advices/ideas
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
10:05 p.m.
New subject: [trinity-devel] cmake build system - need advices/ideas
On Tuesday 05 October 2010 07:21:28 Timothy Pearson wrote:
[...]
I commited all CMake files. Now please create shared cmake directory (you will
find it in kdelibs root).
[...]
I forgot about pthreads and cups, also present on most distros (and very
important for trinity, actually).
[...]
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). 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. Thank you once again for undertaking this large task!
This is a tiny contribution for a desktop environment wich I use for already
10 years.
--
Serghei
6 Oct
6 Oct
12:02 a.m.
New subject: [trinity-devel] cmake build system - need advices/ideas
On Tuesday 05 October 2010 07:21:28 Timothy Pearson
wrote:
[...]
I commited all CMake files. Now please create shared cmake directory (you
will
find it in kdelibs root).
OK, done in SVN revision 1182913. When you want to modify the shared
CMake module files, you can do so in the <svn-root>/kde-common/cmake
directory, and the changes will be propagated to all Trinity modules in
the <svn-root> directory.
Let me know if you have any questions/problems!
Tim
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).
4952
days inactive
4954
days old
3 comments
2 participants
participants (2)
-
Serghei Amelian -
Timothy Pearson