Message: previous - next
Month: October 2010

Re: [trinity-devel] cmake build system - need advices/ideas

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 4 Oct 2010 23:21:28 -0500
> 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

> 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

> 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:
> 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!