4 Dec
2012
4 Dec
'12
9:57 p.m.
I am trying to build it within a chroot, but unless I
am doing that
wrong I do not know what I need to do. :( I am also not opposed
to
uninstalling my current version of trinity and working
from a
different environment, whatever is the best way to do it. I can
use
qemu or virtualbox. It does not matter to me. if there
is a
specific
way that one would suggest building them please let me
know what it
is, even if it a little unorthodox.
I build for Slackware. I have only one computer.
For comparison testing, I have the following virtual machines:
Slackware 12.2 with KDE 3.5.10
Slackware 13.1 with Trinity 3.5.13
I use both virtual systems to compare how things used to run and to
determine whether a bug or behavior is legacy from either system or
new or a regression in R14.
I still work primarily with Slackware 13.1 32-bit as my main
production system, although I also have a newer Slackware 14.0 64-
bit system. Within my 13.1 32-bit system I use a chroot in konsole
to build R14 packages for 13.1 32-bit.
As I have only one computer, I have separate partitions on my
system for Slackware 13.1 64-bit, 13.37 32-bit and 64-bit, 14.0 32-
bit and 64-bit, and Current 32-bit and 64-bit. Typically I don't
build often in any of those systems. When I find a nice quiet spot
in the R14 development, where everything builds without incident
and usage remains stable, then I reboot my system and will run a
full package build in one of the other systems. Most often I pick
the Slackware 14.0 64-bit environment.
My Slackware 14.0 64-bit production and build environments are on
separate partitions. Almost always I run those non-13.1 builds at
night while I sleep and I don't need the computer.
On my to-do list is to create virtual machines for each build
system and to use the existing build environment partitions as raw
devices in the virtual machines. That will provide me flexibility
to support the other systems without rebooting.
A sane approach, when the budget allows, is to use a second machine
that hosts all of these build environments.
Most people have no need or desire to support multiple systems.
Just focus on building against the current system. For that a
chroot is fine. Virtual machines work too, but I find virtual
machines too slow for long build runs.
Although written for Slackware, here is a good tutorial about
creating a chroot:
http://slackworld.berlios.de/2007/chroot_howto.html
In the past, in all of my build environments, I remove all KDE4
related packages. I do that create as pure a build environment as
possible. I have been removing Qt4 as well, but I'll need to change
that in order to build and test some of the newer packages Trinity
provides.
The cmake packages don't have a problem correctly finding (T)Qt3
rather than Qt4. The automake packages tend to get confused, but
the work-around is to explicitly declare where to find the (T)Qt3
packages:
--with-qt-dir=${QTDIR}
--with-qt-includes=${QT_INCLUDE_DIR}
--with-qt-libraries=${QT_LIB_DIR}
In all of my build environments I don't use any desktop environment
or window manager. I run my sole chroot from a terminal window and
all other build environments from the console.
A sane approach is to focus on just building one package at a time
in the order suggested in the wiki. Get TQt3 to build. Then
tqtinterface. Etc.
The Trinity wiki and Arch web site should provide the gritty
details. I'm guessing the Arch web site for Trinity provides all
build scripts.
I believe most of us use a parent/master script to build each
package successively without user intervention.
The 3.5.13.x branch is for back porting patches. Therefore the
primary build environment uses the R14 development branch.
Darrell