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
On Tue, Dec 4, 2012 at 4:57 PM, Darrell Anderson darrella@hushmail.com wrote:
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
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I wil give it a go again later, perhaps I was just out of it. But I don't recall being that out of it. Hmmm. Guess it is time for me to find out, once I get home.
-
Darrell Anderson -
pauline martin