Hi Cliff,
Cliff Brake wrote:
Sounds interesting. I use OE extensively and it works well for what I
do. How does this solution handle cross compiling (for example ARM
architectures)? Can you point me to some reading or Google search
phrases. How is it different/similar to OE or scratchbox?
I always had portage in mind as soon as i started my embedded job about
1 year ago - I looked at OpenEmbedded but found that compiling bitbaker
always failed - Then I (and others) tried to get my board
(embeddedarm.com) supported in OpenWRT, but the developer never ended up
doing anything with the boards we gave him.
What my solution does, is create a chroot environment (much like how one
goes about a stage1 gentoo installation), and installs crossdev.
When the actually building takes place, it simply enters the chroot, and
you use 'xmerge' (see gentoo docs) to install the package, automatically
generating a binary tarball.
I haven't used OE or scratchbox actually, but I knew what my own
requirements were:
1) support multiple configurations
- varies on a per-client or per-application basis
which basically means you can use your embedded
system to run several different applications
customized for various clients, including varying
default configuration files, source patches, and
service definitions (through portage overlays)
- you can copy configuration to a different target
(i.e. the same app on different hardware)
- a configuration is basically the same as an overlay
- developers are free to impose a strict group of
GENTOO_MIRRRORS with their specific overlays and
portage trees.
2) support multiple targets (architectures)
- program creates a directory called 'toolchains'
and each toolchain resides in its own directory.
- support toolchain version numbers, so the above
directories would be called something like
'arm-softfloat-gnu__${binutilsver}__${libcver}__${kernelver}__${gccver}
- You can share the same toolchain between
configurations
(i.e. multiple applications can run on the same hardware)
- you can copy a configuration to a different target.
3) support a devel and stable profile for each configuration
This might not be so obvious, but a new embedded root filesystem image
is generated based on the active profile in the selected configuration,
not just on the configuration itself.
As i mentioned earlier, the above list only partially accounts for the
complexit of the app. Another big job is deciphering the way that
crossdev installs the libraries and the way that gcc-config deals with
cross-compiling (i.e. where are the compiler profiles for gcc-config,
where is the c library, where are the headers & asm files, where do we
store application libraries, etc).
This is due to the fact that the system should support more than one
toolchain - that is a requirement that I imposed myself. However, the
reason for this complexity, is because this app exploits a sort of
backdoor within portage that I'm not sure has been leveraged yet.
That is, the mechanism for entering and exiting the chroot is really the
key - and also the __really__ complicated part.
This app is intended to mount -o bind and unmount the necessary
directories, create / copy / destroy the necessary files, and perform
all sanity checks to ensure that _inside_ the buildroot all functions as
expected - for the selected target, configuration, and profile. It goes
without saying that something done with one profile should be completely
independent of something done with another profile.
The installation directory would look something like this:
$BR_HOME/
toolchains/
x86/
arm-9tdmi-linux-gnu__${binutilsver}__ ...
arm-softfloat-linux-uclibc__${binutilsver}__ ...
x86_64/
arm-9tdmi-linux-gnu__${binutilsver}__ ...
sparc/
arm-softfloat-linux-gnu__${binutilsver}__ ...
buildroots/
x86/
/bin
/usr
* portage/
* target -> arm-9tdmi-linux-gnu
* arm-9tdmi-linux-gnu
...
* /sysroot
* /binpkgs
x86_64/
sparc/
portage/
I hope that offers a bit more information. There is still a lot of work
to do here, but at least it's contained, portable, etc.
Likely, a non-interactive mode will also be developed, where commands like
cp config <src_target> <dest_target>
rm profile <target> <config> <profile>
make sysroot <target> <config> <profile>
will be parsed and so on... allowing lots of possibilities ;-)
~/Chris
--
[email protected] mailing list
