Hi,
Being that 3.5.12 is on the verge of being released, I've decided to
include this release in BLFS to replace the aging 3.5.10.
Given that KDE 4 has rapidly changed quickly, we can't keep up with
the pace, and that stupid cmake.
I've also decided to build RPMs of the KDE 3.5.12 release. They'll be
built for Mandriva, Fedora, and SuSE :)
What configure options would you recommend for stuff like this?
I saw a thread on trinity-devel, but given the fact that I just
subscribed (when I should have done so earlier -.-"), I don't have the
emails.
--
later, Robert Xu
Hello,
As I see, in kde4 api-dox are not handled anymore by building system (actually
apidox is not handled by autotools anyway in kde3, but by script named
doxygen.sh). Is there any reason to include apidox support in cmake scripts?
--
Serghei
I'm wrapping my head around something new.
In the past I have been copying the svn package contents to tmpfs and working there with my compiles. That habit came from being accustomed to building packages from a source tarball. The source tarball is unpacked to a temporary working area and then compiled. With svn, something to which I am new, I maintained that habit by copying the package contents.
Trinity is huge and compiling the entire core package suite requires 6 hours even on a dual core system. I could live with that if I knew the packages always compiled 100% of the time. That is a normal expectation with tarballs, but is not the case in a dynamic svn environment. There always is some degree of breakage. Hence a previous suggestion to use ccache.
I have compiled kernels for many years. Being new to svn I did not understand that, much like the kernel, I don't have to image package sources from the svn tree but can work directly in that directory. Like the kernel I need only use 'make clean' to restore the svn tree. I then can use ccache to create compiling caches, which should dramatically reduce compile times.
If I understand correctly, then in my build scripts I need to do the following:
================================
WAS:
(snippet from arts package build script)
echo "Copying $PRGNAM source files to $TMP..."
cp -a $SVN_SOURCES/dependencies/$PRGNAM $TMP/ || exit 1
cd $PRGNAM || exit 1
echo
echo "Building make and config files..."
echo
echo "Package will be stored at $OUTPUT."
echo
cp -p "$LIBTOOLM4" admin/libtool.m4.in
cp -p "$LTMAINSH" admin/ltmain.sh
make -f admin/Makefile.common
echo
echo "Finished building make and config files."
echo
chown -R root:root .
CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
--prefix=${PREFIX} \
--sysconfdir=${SYSCONFDIR} \
--libdir=${LIBDIR} \
--disable-debug \
--program-prefix="" \
--program-suffix="" \
--build=$ARCH-slackware-linux
make $NUMJOBS || exit 1
make install DESTDIR=$PKG
================================
CHANGE TO:
echo "Changing to $PRGNAM source files in SVN..."
cd $SVN_SOURCES/dependencies/$PRGNAM || exit 1
echo
echo "Building make and config files..."
echo
echo "Package will be stored at $OUTPUT."
echo
cp -p "$LIBTOOLM4" ./admin/libtool.m4.in
cp -p "$LTMAINSH" ./admin/ltmain.sh
make -f ./admin/Makefile.common
echo
echo "Finished building make and config files."
echo
chown -R root:root .
make clean
if [ -x /usr/bin/ccache ]; then
CC="ccache gcc"
echo "Using ccache. Unless configured otherwise, the cache is stored in $HOME/.ccache."
echo
else
CC="gcc"
fi
CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
$CC ./configure \
--prefix=${PREFIX} \
--sysconfdir=${SYSCONFDIR} \
--libdir=${LIBDIR} \
--disable-debug \
--program-prefix="" \
--program-suffix="" \
--build=$ARCH-slackware-linux
make $NUMJOBS || exit 1
make install DESTDIR=$PKG
================================
Do I have the correct idea?
Thanks much!
Darrell
I have been thinking how we might provide binary packages for Slackware 12.2
I'm hoping that if binary packages are available, in addition to build scripts at my site, that interest will increase among Slackware users. Although many Slackers build their own packages, many do not. Yet if they can download the final packages they might spark new interest in Trinity.
I don't have the bandwidth at my meager web site to host packages.
You have offered to host packages. How do we want to do this?
If we wait until the official 3.5.12 tarballs are available, I can build those final packages. I just need to get them to you.
We would need to post and test a link at your web site just like the other links.
If we coordinated this then you could include Slackware 12.2 as part of your release announcement.
Darrell
Nice screen grabs. I'll mildly recommend choosing non-Kubuntu branded screen shots. Otherwise people will think Trinity is Kubuntu-specific. That seems to be the consensus opinion when browsing the web. The fact that Trinity now builds and runs on Slackware 12.2 might somewhat alleviate that belief.
I revised the text and editorialized. No screen shots yet (I don't yet know how), but please review.
I don't have the hang of how to use the online editor. I don't know why when I paste text from a text editor the entire text is enclosed in a gray box. Please share if you know why or how to fix. I don't find the editor at all intuitive or friendly.
When were the KInfoCenter options moved to KControl?
Darrell
Looks like everything builds that I try to build. That is good news! Yet there remain some build issues.
I can't build libcarddav. For me that is a luxury package. I won't cry if the package is not installed. Yet I presume a handful of people will want to use the package. libcaldav builds fine here.
Do I presume correctly that libcaldav provides some additional functionality although libcarddav is not installed?
I can't build tqtinterface directly within the SVN directory. I have to copy the tqtinterface tree to a temporary location and build clean from there, much like building from a tarball. I can build tqtinterface within the SVN directory only once. Thereafter the build always fails. I can build all other packages directly within the SVN directories.
Is this a bug with tqtinterface?
I seem unable to build any package after I run 'make clean' within each package SVN directory. Perhaps this is a conceptual error on my part in the way I use the command in my build scripts. Yet seems that occasionally I should clean house before attempting a full build run.
What is the correct way to clean house in SVN?
I configured my build scripts to ccache. Yet I see no difference in build times. There are files in the cache, the log updates, the log and stats show there are cache hits. Yet the process took 8 hours overnight to build all core, support, and several non-core packages. I don't know whether 8 hours is the best I can do or whether I have something configured incorrectly.
Anybody have theories why I see so little difference?
I need to test building from source tarballs rather than svn.
Although not yet official, can we get a web link for developer testing of 3.5.12 source tarballs?
I still have about a half dozen non-core applications that need build scripts and testing. I use those packages regularly and at least those non-core packages need my attention if I am to fully embrace Trinity.
I have yet to test building the core packages with external support packages installed such as krb5, avahi, lua, OpenEXR, GraphicsMagick, and PostgreSQL.
Although I now presume a hard freeze except for fatal bugs, several non-fatal bugs and usability issues slipped through untouched in our recent discussions. I will sift through the discussions and submit formal bug reports and feature requests in the bugzilla.
Darrell
> Trinity 3.5.12 is not yet officially released, but I suspect we now are
close to a serious freeze. I would like to address future plans. This is
just my rambling.
Correct; the 3.5.12 release is in a little under 4 days so everything
should be finalized at this point.
> I have seen conversations about moving to cmake. Then there is the
tqtinterface support moving toward the goal of being compatible with
qt4.
> I presume moving to cmake means all build scripts have to be revised,
not
> to mention all the testing and debugging that follows such a change. I'm
exhausted with getting build scripts to function in Slackware, let alone
having to consider starting all over again.
No. My intention is to provide the older Automake system in parallel with
CMake for at least a couple of releases. This will allow time for the
CMake system to stabilize fully, while also permitting Trinity to build on
newer systems. The latter is what makes the CMake conversion so critical;
Automake (and therefore the Trinity build process) has already started to
fail on the latest distributions.
> In the short term I hope serious attention is provided after 3.5.12 to
dramatically reducing the number of existing bug reports and enhancement
requests.
I agree with this and will address it on-list after release.
> I'd like to see 3.5.13 focus solely on the bugzilla. Possibly too,
resolve
> significant bugs and enhancement requests from the original KDE 3
bugzilla. Apparent to me of late is that the KDE developers abandoned
3.5.x long before the final 3.5.10 release. The patches committed from
the
> Chakra project, Suse, and even Slackware is evidence of that. Many of
those patches are fairly old and never got merged into the KDE SVN tree.
I'd like to see cmake and qt4 support scheduled for a subsequent
release.
> Can the transition to cmake be scheduled for 3.5.14 or 3.6? New bugs
will
> be introduced once the transition to cmake begins, thereby fattening the
bugzilla. This is what happened with the original KDE developers. They
always focused on bling and seldom spent serious time adding polish to
what already existed.
CMake support is critical to the continued viability of the project, and
therefore I don't think it can wait. Breakage concerns are minimal, as it
will be provided fully in parallel with the existing build system.
Qt4 support is another matter. Without significant help I honestly don't
see that becoming viable for at least several releases. However, work can
slowly continue on it without the risk of breaking existing software, as
the Qt4 portion of the compatibility layer is completely isolated from the
Qt3 portion.
> The release schedule for Trinity does not have to coincide with Ubuntu
releases. If 3.5.13 focused on bugs and minor enhancments, 3.5.13 could
get released in only two or three months. I think the Trinity schedule
should be independent of Ubuntu.
Not sure here. Ubuntu is a primary consumer of the Trinity project, in
addition to having one of the fastest release cycles (6 months) of the
various distributions Trinity supports. As a result, having the releases
synchronized has worked out fairly well in the past.
> Dramatically reducing the bugs and enhancement requests in 3.5.13 would
provide a nice long-term stable desktop. That then would provide
breathing
> room to migrate to cmake and qt4.
> My own hope is 3.5.13 focuses on bugs and minor enhancements, not whole
new features. That is, add the polish the original KDE devs never added.
Create the stable desktop that KDE 4 isn't.
Working on it! ;-) Remember that unfinished features can be disabled for
release...
Just my $0.02.
Tim
Trinity 3.5.12 is not yet officially released, but I suspect we now are close to a serious freeze. I would like to address future plans. This is just my rambling.
I have seen conversations about moving to cmake. Then there is the tqtinterface support moving toward the goal of being compatible with qt4.
I presume moving to cmake means all build scripts have to be revised, not to mention all the testing and debugging that follows such a change. I'm exhausted with getting build scripts to function in Slackware, let alone having to consider starting all over again.
In the short term I hope serious attention is provided after 3.5.12 to dramatically reducing the number of existing bug reports and enhancement requests.
I'd like to see 3.5.13 focus solely on the bugzilla. Possibly too, resolve significant bugs and enhancement requests from the original KDE 3 bugzilla. Apparent to me of late is that the KDE developers abandoned 3.5.x long before the final 3.5.10 release. The patches committed from the Chakra project, Suse, and even Slackware is evidence of that. Many of those patches are fairly old and never got merged into the KDE SVN tree.
I'd like to see cmake and qt4 support scheduled for a subsequent release. Can the transition to cmake be scheduled for 3.5.14 or 3.6? New bugs will be introduced once the transition to cmake begins, thereby fattening the bugzilla. This is what happened with the original KDE developers. They always focused on bling and seldom spent serious time adding polish to what already existed.
The release schedule for Trinity does not have to coincide with Ubuntu releases. If 3.5.13 focused on bugs and minor enhancments, 3.5.13 could get released in only two or three months. I think the Trinity schedule should be independent of Ubuntu.
Dramatically reducing the bugs and enhancement requests in 3.5.13 would provide a nice long-term stable desktop. That then would provide breathing room to migrate to cmake and qt4.
My own hope is 3.5.13 focuses on bugs and minor enhancements, not whole new features. That is, add the polish the original KDE devs never added. Create the stable desktop that KDE 4 isn't.
Darrell
