Trinity options (Was: Re: cmake inclusion?)
dj at linuxfromscratch.org
Sun Dec 12 23:14:34 PST 2010
On 11/28/2010 02:17 PM, Robert Xu wrote:
> On Sun, Nov 28, 2010 at 14:30, DJ Lucas <dj at linuxfromscratch.org> wrote:
>> On 11/28/2010 12:55 PM, Robert Xu wrote:
>>> Hi all,
>>> I finally have some working cmake scripts for Trinity, courtesy of
>>> samelian on Freenode, since we do not want to use a crappy and old
>>> I'm testing them right now, which brings me to another subject: Will
>>> cmake be included into BLFS?
>> Either now or later. If you've got working scripts for Trinity, then now
>> is as good a time as any. I'm currently prepping for Xorg-7.6. Looks
>> like we are waiting on only a couple of modules (libdrm-2.4.23,
>> evdev-2.6.0, xf86-video-intel-2.14.0, and xorg-server-1.9.3, and a
>> couple of lesser important packages that escape me right now). Does
>> cmake drag in any deps that aren't a part of the book as it is now?
> As far as I'm aware, no.
> Hm. All I am waiting on now is for scripts for arts and tqtinterface,
> unless I just missed them.
> Once the cmake scripts for those come in, I'll test them. Hopefully we
> can throw in a minimal Trinity system to replace that old KDE3 :)
> *hails samelian, he is the greatest for making Trinity work with cmake ;P*
> You can see what I've seen so far at http://lincom.ietherpad.com/7
Sorry in advance for the length of this post, but lots of work to be
done and I want to make sure we are on the same page.
I pulled everything from SVN. Looks like everything is exactly 3.5.12,
with openssl-1.0.0b fixes and cmake scripts. I can roll new tarballs
from there if desired, or can make patches to add the openssl and cmake
changes. I'm more inclined to roll our own simply because of the ugly
(non-standard) layout. If it were only arts and tqtinterface, I could
deal (and still _can_), but I don't want to explain the same thing 20
times in the book. I'd hope that going forward, the release tarballs
will be a little more polished. I might get in touch with the maintainer
and see if that can't happen for future releases after we have a nice
clean build layout in the book.
Also, reviewing your notes at the above link. Looks like tqtinterface
builds fine without qt4 (moved it out of /opt/qt4 and removed from
config and refreshed the linker cache). I haven't gotten into the meat
of it yet, but if this is any indication of the quality of the cmake
build system, I'm thinking I might actually like this beast, just a
little learning curve to deal with.
Going back to tqtinterface, couple of things I didn't understand. First
is that the release version is defined (MAJOR,MINOR,MICRO) as 3.5.12,
but the soname of the library is 4.2.0. Second, I see the qt4
directories...are these required for later? I was moving on and building
deps for arts, but I haven't actually went beyond tqtinterface yet as I
don't want to get too far in and then have to start over (not that it is
really a big deal).
No mention is made of QT4 other than tqtinterface providing the
'groundwork' (or intermediary step as I understood it) for migrating to
QT4. Several other examples are provided that highlight dependency
differences from the latest official KDE release, so I'm not convinced
by that document that QT4 is required yet. The fact that tqtinterface
builds without QT4 seems to provide further evidence that it is not
required. Since it really is not a big deal, I'm going to crash tonight,
and push forward tomorrow without QT4 unless you know for certain that
my observations are incorrect.
Finally, I ask your opinion on provided packages. Barring the additional
bindings, do any other packages need to be exported beyond koffice and
k3b (already in the book) in order to to provide a fairly complete
-- DJ Lucas
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
More information about the blfs-dev