Okay, so I had a different definition of "core" than everybody else. :)
Yes, there were many problems with automake. I won't pretend to understand the nuances of building packages. I know that last summer and autumn I reported many build issues that Tim resolved. I probably worked Tim into a frazzle. :)
I have no doubts about cmake. I have seen the improved build times and the fewer build error messages.
I am waiting to build the remaining packages of the traditional suite packages (those packages I listed, not the third tier applications packages). As soon as the word is given I'll start building, testing, and reporting what I can.
Yes, I can build the four core packages. I haven't installed them. I'll install and test those four packages if other people start quashing bugs that involve only those packages. Some reports that might fit that description:
251, Kicker/panel has no configuration option to stop scrolling among apps 252, Panel handle pointers (the black arrow heads) are too large. 258, ksmserver: Logout confirmation fadeaway is too slow with older hardware 270, KFileDialog: Provide an option to disable tooltip popups when hovering over long file names 291, DCOPReply messages in xsession-error log 293, Kde-config Incorrectly Creates a Profile Folder in the System root directory 294, KControl Zeroconf Service Discovery Module 296, New Trinity Profile Error Messages 298, Libpng Warning Messages 299, Samba: Something in Trinity Tries to Access Samba Config Files 300, Scroll Bar Width 303, Safely Unmount does not always remove the icon from the desktop 306, Desktop Device Icon Arrangement 335, Konqueror Icon Activation Effect 385, Unmounted removable device icons do not appear on the desktop 386, Show Desktop behavior 387, Kicker/Panel Clock Font Display Looks Weird 389, Activation Effects 392, Desktop Device Icon Placement 427, NumLock light does not reflect actual state
Darrell
--- On Mon, 3/14/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Downgrading autoconf/automake To: trinity-devel@lists.pearsoncomputing.net Date: Monday, March 14, 2011, 4:54 PM
On Mon, Mar 14, 2011 at 5:04 PM,
Darrell Anderson
wrote:
As I wrote in my previous post, I haven't YET
given up.
Yes, I have noticed the build time difference with
tqtinterface, arts,
kdelibs, and kdebase. :) Thank you Serghei!
The core Trinity modules are almost ported to
cmake? Hmm. I don't see
that in my local svn tree. I updated svn
yesterday. I see the following:
tqtinterface arts kdelibs kdebase kdegraphics kdevelop kdewebdev kdepim
Core packages with no CMakeLists.txt:
kdebindings kdeaccessibility kdeutils kdemultimedia kdenetwork kdeadmin kdeartwork kdegames kdetoys kdeedu kdeaddons kdesdk
Also, the ones that you list directly above (accessibility, utils, etc.) are relatively simple build-wise. libs, base, pim, kdevelop, etc. are NOT simple and they have taken longer to port to CMake.
If someone wanted to try to get Automake repaired for the modules for which CMake is not yet ready, that's fine with me, as long as it does not detract from the CMake effort. I will not be able to help in that effort, as I am working on building Debian packages and fixing bugs. Personally, having looked at CMake's build files, I believe it to be a far better solution. There were too many ways Automake could fail, as I think Darrell knows. ;-)
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting