On 7/26/07, Marius Vollmer <[EMAIL PROTECTED]> wrote: > From my point of view, the host and target distributions should be as > independent as possible. The host could be Debian, or Redhat, or > Nokia's internal Linux, or OSX, or even Windows.
There are many, many ways to solve this, starting from running a chroot and continuing all the way up to vmware & co. SB2 would then be used in that "virtualized" environment. > The SB2 idea seems to be that there is only one distribution, and SB2 > is a clever hack to allow you to compile for a different target > architecture than the host one without having to worry about > cross-compilation complexities too much. Pretty much yes. SB1 tried to pretend that it's a "generic" cross-compilation tool, but ended up being neither generic nor specific. > Thus, from what I understand about SB2, I would characterize the > situation so that the "sb2" command takes you from the host > architecture to the target architecture, but stays in the same > distribution. The host and target architecture environments are > separate installations of this one distribution, and you need to make > sure that both of them are properly up-to-date and syncronized. All target distributions have build requirements, of course we could construct maemo to be a totally non-debian distro but still use debian/unstable as build requirements. It would be weird, but certainly possible. It's pointless to pretend that we could construct a new distro that could use any linux distro from the past five years as build requirements. That just won't work. Using something like the project-builder from ubuntu might be a way to provide the build deps on a number of different host distros. > Programs that run inside the target architecture environment get a > native environment to run in and a properly emulated CPU to run on. > Thus, they never know that they are effectively being cross-compiled. > This is too slow for some programs like the compiler, so here comes > the clever part of SB2: there is a conceptual second layer of > emulation that emulates the host architecture on the target > architecture with the magical property that the two layers of > emulation cancel each other out and performance actually increases. Well, by default we're really staying in the host as much as possible, it's all path based, so if you access files from let's say /usr/share they are by default the target files, with quite a few exceptions to support running the build tools. I've tried to make sure the build tools get their own files from the host always, this reduces the number of packages that need to be installed for the target, and it's the right thing anyway. > This is a good and simple model, the only thing I don't like about it > is that I can't choose or configure my host environment independently > from the target environment. There are ways to work around this as described above, it would not be smart to include yet another way into sb2. That would only make it bigger with all the downsides of SB1. /lauri _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
