Message: previous - next
Month: December 2014

Re: [trinity-users] Confusion about building from sources (R13.2 on Slack 14.1)

From: Jagged O'Neill <jagged_4tr@...>
Date: Sun, 7 Dec 2014 14:18:11 +0100
On Sun, Dec 07, 2014 at 07:31:24AM -0500, E. Liddell wrote:
> On Sun, 7 Dec 2014 01:56:59 +0100
> > 
> > 1. It doesn't say which release this is about. [...]
> It was ported from the old wiki, so unless someone's changed it
> recently, it's for 13.X.
> > 2. It isn't clear about the build tool to use for the different
> > packages. When talking about the autoconf -> cmake migration, there
> > should be some details of which package in which release is to be
> > done with which build tool, or each package should have a quick note
> > about this in the README or whatever...
> "List of Packages Building with cmake" says " Build everything not in the 
> list above with autotools."  autoconf is part of autotools.
> If you think that's unclear, can you suggest a better way to word it?

No, sorry, I wasn't unclear about that I meant this in conjunction
with point 1.; an Idea would be to make one list for any "initial"
release, and for each subsequent release another list that says
which packages have been migrated to cmake meanwhile.

(One point why I thought this is all about R14 is that the package
names are given as tdelibs, tdebase, etc., while the package files
I downloaded (from are still named kdelibs, kdebase, etc.)

Another idea, IMHO even better would be a table, one row per package,
one column per Trinity release, stating the respective build tool to
use as (a)utoconf, (c)make or (m)anual --- just an idea.

> (That's a sincere question, not an attempt to needle you.  The more people 
> understand the wiki, the more of them will have a good experience with 
> Trinity.)
> > No idea if I should attach the error output from a cmake approach.
> Do, please, since that's the expected build system for tqtinterface.

Okay, the logs are from a run in which I passed "-ldl -lpthread -lX11
-lXext -lz -ljpeg -lmng -lpng" already. There's not a lot missing,
but this makes the error log quite some bytes shorter.

Thanks a lot!
valgrind python -c 'for i in range(1,1): print(i)' 2>&1 | grep error