What caveats should I know with downgrading autoconf/automake?
The port to cmake is a wise long-term strategy but will take time. While svn remains in a mixed autotools and cmake environment, both sets of build tools are needed during the transition.
As I am already two releases behind, I was thinking about moving to the next release of Slackware, which is now in RC status. That move also will allow me to test Trinity in an environment with KDE4 installed.
That upcoming Slackware release comes with autoconf-2.68 and automake-1.11.1.
As explained to me, I cannot build KDE 3.5.10 or Trinity with that version of those tools.
I was thinking about updating to the new Slackware release and then temporarily downgrading to autoconf-2.63 and automake-1.10.1 so I can build and help test Trinity during the long-term port to cmake.
I presume that if I want to build third-party packages for the new Slackware release, I might have to toggle to autoconf-2.68 and automake-1.11.1 to ensure no compatibility problems.
Perhaps I need only downgrade autoconf and not automake. I have no clue if that is possible too.
Will this work?
Darrell
On Thu, Mar 10, 2011 at 3:14 PM, Darrell Anderson humanreadable@yahoo.comwrote:
What caveats should I know with downgrading autoconf/automake?
The port to cmake is a wise long-term strategy but will take time. While svn remains in a mixed autotools and cmake environment, both sets of build tools are needed during the transition.
As I am already two releases behind, I was thinking about moving to the next release of Slackware, which is now in RC status. That move also will allow me to test Trinity in an environment with KDE4 installed.
That upcoming Slackware release comes with autoconf-2.68 and automake-1.11.1.
As explained to me, I cannot build KDE 3.5.10 or Trinity with that version of those tools.
I was thinking about updating to the new Slackware release and then temporarily downgrading to autoconf-2.63 and automake-1.10.1 so I can build and help test Trinity during the long-term port to cmake.
I presume that if I want to build third-party packages for the new Slackware release, I might have to toggle to autoconf-2.68 and automake-1.11.1 to ensure no compatibility problems.
Perhaps I need only downgrade autoconf and not automake. I have no clue if that is possible too.
Will this work?
IIRC, autoconf-2.65 was the release that was creating problems, right? I'm asking this because if it is so, the Gentoo guys have solved the build problems with autoconf-2.65 on their build scripts.
Best regards, Tiago
Darrell
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
On Monday 14 March 2011 14:12:15 Tiago Marques wrote:
What caveats should I know with downgrading autoconf/automake?
The port to cmake is a wise long-term strategy but will take time. While svn remains in a mixed autotools and cmake environment, both sets of build tools are needed during the transition.
As I am already two releases behind, I was thinking about moving to the next release of Slackware, which is now in RC status. That move also will allow me to test Trinity in an environment with KDE4 installed.
That upcoming Slackware release comes with autoconf-2.68 and automake-1.11.1.
We have exactly autoconf-2.68 and automake-1.11.1 in openSUSE 11.4. KDE 3.5 builds well...
On Mon, Mar 14, 2011 at 10:08 AM, Ilya Chernykh neptunia@mail.ru wrote:
We have exactly autoconf-2.68 and automake-1.11.1 in openSUSE 11.4. KDE 3.5 builds well...
Does openSuSE include a patch to KDE to build it? I remember Robert mentioning a patch Fedora was using for KDE 3.5 that failed with TDE, but if openSuSE has a patch, we might be able to examine it and the Fedora patch to see if we can adapt them to TDE.
When I first tried compiling TDE after 3.5.11, I was on Ark Linux dockyard-devel, on which was installed the most recent devel tools of the time, and I couldn't get very far, then discovered the autotools problem mentioned on the wiki. I forget what the error was, but it wasn't very fun.
On Monday 14 March 2011 19:34:25 Kristopher Gamrat wrote:
We have exactly autoconf-2.68 and automake-1.11.1 in openSUSE 11.4. KDE 3.5 builds well...
Does openSuSE include a patch to KDE to build it?
There are about 200 patches. Do you know any distro that provides KDE without any patches?
On Mon, Mar 14, 2011 at 12:53 PM, Ilya Chernykh neptunia@mail.ru wrote:
On Monday 14 March 2011 19:34:25 Kristopher Gamrat wrote:
We have exactly autoconf-2.68 and automake-1.11.1 in openSUSE 11.4. KDE 3.5 builds well...
Does openSuSE include a patch to KDE to build it?
There are about 200 patches. Do you know any distro that provides KDE without any patches?
I've never looked at the source files for any distro other than Ark Linux, so I wouldn't know.
On Mon, Mar 14, 2011 at 3:07 PM, Kristopher Gamrat pikidalto@gmail.com wrote:
On Mon, Mar 14, 2011 at 12:53 PM, Ilya Chernykh neptunia@mail.ru wrote:
On Monday 14 March 2011 19:34:25 Kristopher Gamrat wrote:
We have exactly autoconf-2.68 and automake-1.11.1 in openSUSE 11.4. KDE 3.5 builds well...
Does openSuSE include a patch to KDE to build it?
There are about 200 patches. Do you know any distro that provides KDE without any patches?
I've never looked at the source files for any distro other than Ark Linux, so I wouldn't know.
But surely there's a utility that can search through the contents of the patches and pull out possible patches to look at?
On Mon, Mar 14, 2011 at 15:09, Kristopher Gamrat pikidalto@gmail.com wrote:
But surely there's a utility that can search through the contents of the patches and pull out possible patches to look at?
no.
On Mon, Mar 14, 2011 at 3:10 PM, Robert Xu robxu9@gmail.com wrote:
On Mon, Mar 14, 2011 at 15:09, Kristopher Gamrat pikidalto@gmail.com wrote:
But surely there's a utility that can search through the contents of the patches and pull out possible patches to look at?
no.
...wow, I'd have thought there was, considering that patches are basically plain text files. First time I can say that I've seen something in Windows before I saw in in F\OSS.
On Mon, Mar 14, 2011 at 3:10 PM, Robert Xu robxu9@gmail.com wrote:
On Mon, Mar 14, 2011 at 15:09, Kristopher Gamrat pikidalto@gmail.com wrote:
But surely there's a utility that can search through the contents of the patches and pull out possible patches to look at?
no.
...wow, I'd have thought there was, considering that patches are basically plain text files. First time I can say that I've seen something in Windows before I saw in in F\OSS.
Um, yes there is. Do this:
find . | xargs grep "Makefile.am" -sl
from within the directory containing the patches
Tim
On Mon, Mar 14, 2011 at 15:15, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Um, yes there is. Do this:
find . | xargs grep "Makefile.am" -sl
from within the directory containing the patches
Tim
Oh... the find way... never used it too much. :-\
On Monday 14 March 2011 22:17:01 Robert Xu wrote:
kb9vqf@pearsoncomputing.net wrote:
Um, yes there is. Do this:
find . | xargs grep "Makefile.am" -sl
from within the directory containing the patches
Tim
Oh... the find way... never used it too much. :-\
Usually the patch name suggests what the patch is for. For example, I would not expect a patch named "icon-theme-rearrange-fix" to contain something related to automake issues.
On Mon, Mar 14, 2011 at 3:23 PM, Ilya Chernykh neptunia@mail.ru wrote:
Usually the patch name suggests what the patch is for. For example, I would not expect a patch named "icon-theme-rearrange-fix" to contain something related to automake issues.
Usually, and should be, but not always. It's also possible to not have the name related to the patch. For example, "kde3-yeargh.patch" might just be named in frustration, but not to what it's fixing (unless it's adding pirate translations to kde, in which case a better name would be "kde3-pirate-translations", but that'd be a useless patch anyway ;-) ).
My 2 cents:
I appreciate --- and have accepted --- the need to move to cmake. Even the KDE4 developers moved to cmake.
The conversion to cmake is going to take time. A long time.
Something broke after 3.5.12. On Slackware 12.2 I can build Trinity 3.5.12 but not SVN. The twist is I am trying to build SVN on the same system with the same tools that successfully builds 3.5.12. Therefore I am inclined to think the problem is with the SVN automake configuration files.
I understand why the packages that have been ported to cmake require a newer version of cmake, but not those packages that should still build with automake.
Past conversations indicate something needs to be patched in some header files to build with newer versions of automake. Is that a technical challenge that is difficult to overcome? Or is the reason everybody is waiting for the cmake port to complete and prefer not to expend anymore energy with automake?
In the mean time some people cannot build Trinity at all.
I have not yet tried to build Trinity or KDE on a newer Slackware system. I intend to try soon.
I lack the skills to patch bugs or convert to cmake, or patch automake. I can build packages and test bugs, but I can't now do that.
I won't wait forever for Trinity to be buildable. The same is true for end-users who quietly have been waiting for Trinity. They can't even download packages because none are being built.
Because I can't build Trinity, I have been exploring KDE4 in a virtual machine. I am not warm and fuzzy with KDE4, but as I test that desktop I am acclimating to the new way of doing things. I am learning to strip cruft and reduce the noise KDE4 makes. Slowly I am massaging KDE4 into something I could use --- despite my preference for KDE3/Trinity.
I am not yet throwing in the towel. Yet if within the next several weeks I cannot build Trinity or KDE 3.5.10 on any Slackware system then I will face the decision of moving on.
Trinity has much potential. I do not look forward to that day.
Darrell
On Mon, Mar 14, 2011 at 3:43 PM, Darrell Anderson humanreadable@yahoo.com wrote:
My 2 cents:
I appreciate --- and have accepted --- the need to move to cmake. Even the KDE4 developers moved to cmake.
The conversion to cmake is going to take time. A long time.
Something broke after 3.5.12. On Slackware 12.2 I can build Trinity 3.5.12 but not SVN. The twist is I am trying to build SVN on the same system with the same tools that successfully builds 3.5.12. Therefore I am inclined to think the problem is with the SVN automake configuration files.
I understand why the packages that have been ported to cmake require a newer version of cmake, but not those packages that should still build with automake.
Past conversations indicate something needs to be patched in some header files to build with newer versions of automake. Is that a technical challenge that is difficult to overcome? Or is the reason everybody is waiting for the cmake port to complete and prefer not to expend anymore energy with automake?
In the mean time some people cannot build Trinity at all.
I have not yet tried to build Trinity or KDE on a newer Slackware system. I intend to try soon.
I lack the skills to patch bugs or convert to cmake, or patch automake. I can build packages and test bugs, but I can't now do that.
I won't wait forever for Trinity to be buildable. The same is true for end-users who quietly have been waiting for Trinity. They can't even download packages because none are being built.
Because I can't build Trinity, I have been exploring KDE4 in a virtual machine. I am not warm and fuzzy with KDE4, but as I test that desktop I am acclimating to the new way of doing things. I am learning to strip cruft and reduce the noise KDE4 makes. Slowly I am massaging KDE4 into something I could use --- despite my preference for KDE3/Trinity.
I am not yet throwing in the towel. Yet if within the next several weeks I cannot build Trinity or KDE 3.5.10 on any Slackware system then I will face the decision of moving on.
Trinity has much potential. I do not look forward to that day.
From what I hear, cmake porting isn't too hard once you get used to it. I will be helping with this once I get my new hard disk (which I will be ordering on Thursday).
As I understand it (someone correct me if I'm wrong), there is too much risk of the autotools api changing again, which is what broke building to begin with, so rather than having to worry about fixing the headers with each new version of autotools, it'd be much easier to just use cmake. I've also heard that a project that is correctly setup for cmake can be easier to work with when doing the actual build than when trying to build with autotools.
From what I hear, cmake porting isn't too hard once you get used to it. I will be helping with this once I get my new hard disk (which I will be ordering on Thursday).
As I understand it (someone correct me if I'm wrong), there is too much risk of the autotools api changing again, which is what broke building to begin with, so rather than having to worry about fixing the headers with each new version of autotools, it'd be much easier to just use cmake. I've also heard that a project that is correctly setup for cmake can be easier to work with when doing the actual build than when trying to build with autotools.
Not to mention the time required for building the following packages:
kdelibs: with Automake: 50 minutes with CMake: 7 minutes
kdebase: with Automake: 60 minutes with CMake: 10 minutes
See a distinct advantage there? ;-) This would greatly help when fixing bugs or adding new features.
Also, from what I can see, the core Trinity modules are almost ported to CMake. I am working through the Debian/Ubuntu build glitches now, and will have a better handle on the current status of things as my builds progress.
Don't give up yet!
Tim
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
Perhap I'm missing something obvious, but that does not seem like "almost" to me. :)
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, 3:19 PM
From what I hear, cmake porting isn't too hard once
you get used to
it. I will be helping with this once I get my new hard
disk (which I
will be ordering on Thursday).
As I understand it (someone correct me if I'm wrong),
there is too
much risk of the autotools api changing again, which
is what broke
building to begin with, so rather than having to worry
about fixing
the headers with each new version of autotools, it'd
be much easier to
just use cmake. I've also heard that a project that is
correctly setup
for cmake can be easier to work with when doing the
actual build than
when trying to build with autotools.
Not to mention the time required for building the following packages:
kdelibs: with Automake: 50 minutes with CMake: 7 minutes
kdebase: with Automake: 60 minutes with CMake: 10 minutes
See a distinct advantage there? ;-) This would greatly help when fixing bugs or adding new features.
Also, from what I can see, the core Trinity modules are almost ported to CMake. I am working through the Debian/Ubuntu build glitches now, and will have a better handle on the current status of things as my builds progress.
Don't give up yet!
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
On Mon, Mar 14, 2011 at 17:04, Darrell Anderson humanreadable@yahoo.com 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
Those are the core Trinity packages.
On Mon, Mar 14, 2011 at 5:04 PM, Darrell Anderson humanreadable@yahoo.com 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
Perhap I'm missing something obvious, but that does not seem like "almost" to me. :)
Those aren't core. The core ends at kdebase. Those are the ones needed to run KDE3/TDE apps.
Most people do expect to see those others packaged, as well as a few of the applications, but we need to compile tqtinterface, arts, kdelibs, and kdebase before any of those will run. The difference is that everything in svn requires the core stuff, but not everything requires the rest, though they may require some of the other stuff depending on what functionality they use.
On Mon, Mar 14, 2011 at 5:04 PM, Darrell Anderson humanreadable@yahoo.com 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
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
On Mon, Mar 14, 2011 at 6:01 PM, Ilya Chernykh neptunia@mail.ru wrote:
On Monday 14 March 2011 23:19:40 Timothy Pearson wrote:
Not to mention the time required for building the following packages:
kdelibs: with Automake: 50 minutes
Even with parallel compiling?
Parallel compiling would probably speed things up, but looking at the results, cmake would still likely be faster when comparing both in parallel.
I remember seeing somewher (I think either IRC or the wiki, will have to check) that some of the stuff doesn't build will in parallel, while some of it does
On Mon, Mar 14, 2011 at 6:01 PM, Ilya Chernykh neptunia@mail.ru wrote:
On Monday 14 March 2011 23:19:40 Timothy Pearson wrote:
Not to mention the time required for building the following packages:
kdelibs: with Automake: 50 minutes
Even with parallel compiling?
Parallel compiling would probably speed things up, but looking at the results, cmake would still likely be faster when comparing both in parallel.
I remember seeing somewher (I think either IRC or the wiki, will have to check) that some of the stuff doesn't build will in parallel, while some of it does
This is true. kdelibs/kdebase don't build in parallel due to some sort of Automake glitch.
As I mentioned before, it is just too easy to mess Automake up in a variety of very hard to trace ways. I can attest to this; the latest autoconf versions won't even find certain core libraries any more. Nothing changed in the Trinity automake files, and I have been unable to resolve the problem despite spending several weeks looking for a fix.
CMake is the future--it offers more functionality, faster build times, less opportunities for breakage, and to top it all off no functionality is lost compared to Automake.
Tim
On Tuesday 15 March 2011 01:27:54 Timothy Pearson wrote:
Even with parallel compiling?
Parallel compiling would probably speed things up, but looking at the results, cmake would still likely be faster when comparing both in parallel.
I remember seeing somewher (I think either IRC or the wiki, will have to check) that some of the stuff doesn't build will in parallel, while some of it does
This is true. kdelibs/kdebase don't build in parallel due to some sort of Automake glitch.
In OBS they both build in parallel, with OBS-default 4 threads. No problems...
On Tuesday 15 March 2011 01:27:54 Timothy Pearson wrote:
Even with parallel compiling?
Parallel compiling would probably speed things up, but looking at the results, cmake would still likely be faster when comparing both in parallel.
I remember seeing somewher (I think either IRC or the wiki, will have to check) that some of the stuff doesn't build will in parallel, while some of it does
This is true. kdelibs/kdebase don't build in parallel due to some sort of Automake glitch.
In OBS they both build in parallel, with OBS-default 4 threads. No problems...
Since you seem to know Automake so well, why don't you try to fix the Trinity Automake files? I would be very interested to know why you are not seeing the same build problems as I and others have seen.
Tim
-
Darrell Anderson -
Ilya Chernykh -
Kristopher Gamrat -
Robert Xu -
Tiago Marques -
Timothy Pearson