10 Mar
2011
10 Mar
'11
3:14 p.m.
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
14 Mar
14 Mar
11:12 a.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Thu, Mar 10, 2011 at 3:14 PM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;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.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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
2:08 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
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...
4:34 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 10:08 AM, Ilya Chernykh <neptunia(a)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.
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
4:53 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Monday 14 March 2011 19:34:25 Kristopher Gamrat wrote:
There are about 200 patches. Do you know any distro that provides KDE without
any patches?
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?
7:07 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 12:53 PM, Ilya Chernykh <neptunia(a)mail.ru> wrote:
On Monday 14 March 2011 19:34:25 Kristopher Gamrat
wrote:
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.
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
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?
7:09 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 3:07 PM, Kristopher Gamrat <pikidalto(a)gmail.com> wrote:
On Mon, Mar 14, 2011 at 12:53 PM, Ilya Chernykh
<neptunia(a)mail.ru> wrote:
But surely there's a utility that can search through the contents of
the patches and pull out possible patches to look at?
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
On Monday 14 March 2011 19:34:25 Kristopher
Gamrat wrote:
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. 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? 
7:10 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 15:09, Kristopher Gamrat <pikidalto(a)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.
--
later, Robert Xu
7:13 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 3:10 PM, Robert Xu <robxu9(a)gmail.com> wrote:
On Mon, Mar 14, 2011 at 15:09, Kristopher Gamrat
<pikidalto(a)gmail.com> wrote:
...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.
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
But surely there's a utility that can search
through the contents of
the patches and pull out possible patches to look at?
no. 
7:15 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 3:10 PM, Robert Xu
<robxu9(a)gmail.com> wrote:
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:09, Kristopher Gamrat
<pikidalto(a)gmail.com>
wrote:
...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.
But surely there's a utility that can search
through the contents of
the patches and pull out possible patches to look at?
no.
7:17 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 15:15, Timothy Pearson
<kb9vqf(a)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. :-\
--
later, Robert Xu
7:23 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Monday 14 March 2011 22:17:01 Robert Xu wrote:
<kb9vqf(a)pearsoncomputing.net> 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.
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. :-\
7:38 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 3:23 PM, Ilya Chernykh <neptunia(a)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
;-) ).
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
7:43 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
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
7:54 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 3:43 PM, Darrell Anderson
<humanreadable(a)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.
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
8:19 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
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
9:04 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
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(a)pearsoncomputing.net> wrote:
From: Timothy Pearson
<kb9vqf(a)pearsoncomputing.net>
Subject: Re: [trinity-devel] Downgrading autoconf/automake
To: trinity-devel(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
9:06 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 17:04, Darrell Anderson <humanreadable(a)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.
--
later, Robert Xu
9:33 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 5:04 PM, Darrell Anderson
<humanreadable(a)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.
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
9:54 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 5:04 PM, Darrell Anderson
<humanreadable(a)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
11:19 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
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(a)pearsoncomputing.net> wrote:
From: Timothy Pearson
<kb9vqf(a)pearsoncomputing.net>
Subject: Re: [trinity-devel] Downgrading autoconf/automake
To: trinity-devel(a)lists.pearsoncomputing.net
Date: Monday, March 14, 2011, 4:54 PM
On Mon, Mar 14, 2011 at 5:04 PM,
Darrell
Anderson
<humanreadable(a)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
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
10:08 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 6:01 PM, Ilya Chernykh <neptunia(a)mail.ru> wrote:
On Monday 14 March 2011 23:19:40 Timothy Pearson
wrote:
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
--
Kris
"Piki"
Ark Linux Webmaster
Trinity Desktop Environment Packager
Not to mention the time required for building the
following packages:
kdelibs:
with Automake: 50 minutes
Even with parallel compiling?
10:27 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Mon, Mar 14, 2011 at 6:01 PM, Ilya Chernykh
<neptunia(a)mail.ru> wrote:
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 Monday 14 March 2011 23:19:40 Timothy Pearson
wrote:
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
Not to mention the time required for building the
following packages:
kdelibs:
with Automake: 50 minutes
Even with parallel compiling?
11:24 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Tuesday 15 March 2011 01:27:54 Timothy Pearson wrote:
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...
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
11:31 p.m.
New subject: [trinity-devel] Downgrading autoconf/automake
On Tuesday 15 March 2011 01:27:54 Timothy Pearson
wrote:
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
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
5064
days inactive
5068
days old
25 comments
6 participants
participants (6)
-
Darrell Anderson -
Ilya Chernykh -
Kristopher Gamrat -
Robert Xu -
Tiago Marques -
Timothy Pearson