Speed, control and quality. You get much faster turnaround and better integration with continuous building / regression testing. This enables much more distributed development.
Note that commercial embedded distributions allow you to cross-compile only software they are providing, with their systems you can't just get some Open Source software from the internet and expect to be able to cross-compile it.
You can specify in which port the Sbrshd daemon listens to connections. When you upgrade to newer Scratchbox with
newer Sbrshd daemon, just run the daemon at different port on the CPU transparency device. When users upgrade to that
Scratchbox version, they just need to change the .sbrsh files in their Sbox home directory to contain the correct
target port number (add ':' after the target IP address, example <ip>:<port>,
192.168.0.100:1202).
If you have installed scratchbox from tar.gz files a list of all environment variables used by scratchbox are
described in /scratchbox/doc/variables.txt. Debian packages install the documentation to
/usr/share/doc/scratchbox-core
In shell scripts:
if [ -f /targets/links/scratchbox.config ]; then echo yes; fi
In Makefiles:
SBOX = $(shell if [ -f /targets/links/scratchbox.config ]; then echo yes; fi)
ifeq ($(SBOX),yes)
# do sbox specific stuff
endif
This information is in 'scratchbox.config' file in a format which can be used both:
In shell scripts:
source /targets/links/scratchbox.config echo $SBOX_CPU
In Makefiles:
include /targets/links/scratchbox.config all: $(SBOX_CPU)-program
Note that 'configure' scripts have a generic way of handling this, above is intended for things that are Scratchbox specific.
[sbox-HOST: ~] > ccache -h
For older (before 0.9.8pre4) scratchbox versions all commands executed with CPU transparency feature are logged to '/tmp/coutransp_$USER.log'. If environment variable SBOX_CPUTRANSPARENCY_VERBOSE has a value (other than '0' or 'no'), a message is outputted to STDERR everytime CPU transparency is used. SBOX_CPUTRANSPARENCY_VERBOSE may cause problems with some configuration scripts
In newer (after 0.9.8-pre4) versions logging of commands executed with CPU transparency is controlled with SBOX_CPUTRANSPARENCY_LOG which is used to provide name of the CPU transparency logfile. If the environment variable is empty logging is disabled.
Run the following command (if you have a shell compiled for your target):
[sbox-ARM: ~] > /scratchbox/tools/bin/misc_runner \
/bin/sh -c "set"
99% of the programs do not need any changes for cross-compilation as nowadays Scratchbox should handle also CPU type configure checks automatically. In case you come across software that queries CPU type in a way Scratchbox can't fake, you can always disable CPU transparency and configure that software manually (assuming it can be cross-compiled normally). For ARM you could do it like this:
export SBOX_DEFAULT_GCC_PREFIX="host-"
export SBOX_DISABLE_CPUTRANSPARENCY=1
CC=arm-linux-gcc ./configure --host=arm-linux
This way you still profit from the Scratchbox sandboxing feature.
Because Scratchbox uses chroot for sandboxing the compilation and its configuration, only file based communication methods (unix sockets, pipes etc) are limited. This can be handled through '/tmp'-directory as Scratchbox shares it with the rest of the system. Usually servers place their sockets into '/tmp' by default and most of others (and their clients) can be told to do that, so there should be no problems.
This is not recommended because Scratchbox CPU transparency requires your machine to do NFS exports and it installs a couple of suid-root / sudo binaries to your system (so that normal users can use Scratchbox).
Try asking your question on IRC channel #scratchbox on Freenode or in one of our mailinglists.
Scratchbox is intended to be used and be usable on developer desktops which are administrated by other people. For compilation root privileges shouldn't be needed. It shouldn't be needed for building packages either, for that fakeroot(-net) should be enough. Root is needed only when you install packages or run the installed software and even this only for very few system software packages. The main purpose of Scratchbox is building software.
Additionally, running Scratchbox as root is an easy way to shoot yourself into foot, and as you're compiling whole distributions in Scratchbox there's a lot of software that might contain e.g. trojans. Sandboxing and faked root privileges make things a bit more secure.
If you've e.g. compiled X server for ARM, and would like to run it as root on the target (because it doesn't run/work correctly without root privileges), you can:
$ ssh root@arm.device
# chroot /home/username/[IP-number]-[target name] /bin/sh
Now that you've been chrooted to Scratchbox directory, you can run as root any software you've cross-compiled in Scratchbox:
# Xfbdev -screen 320x240x16@90 -ac :1 &
Note that not all of the Scratchbox contents are NFS mounted onto target
device, only the relevant directories (see your ~/.sbrsh file for the
details). Also, you should keep an sbrsh session open inside Scratchbox so
that the NFS mounts won't expire while you're working in the other session.
Alternatively, you can start the sbrsh daemon with the
--mount-expiration none option so that it never expires the
NFS mounts.