Gustavo Barbieri wrote: > While trying to build it by hand and also create an ebuild (Gentoo), > I've found out that many other things are hard coded and the build > process is not that usual (ie: doesn't use autotools and stuff like > that). There is any reason?
Scratchbox is a complex piece of software; it's actually closer to an operating system than an application. There are a few reasons why things are like they are: Scratchbox's host tools (including compilers) are dynamic binaries that need to work in the sandbox where the root filesystem is dominated by the contents of the target filesystem. The host tools are linked so that they find correct host libraries from under /scratchbox instead of trying to link against ARM/whatever libraries found in /lib and /usr/lib. The host tools can also be used outside the sandbox environment, so the library location must be the same in either case for that to work. Being able to use the toolchains from outside is handy, but moving the Scratchbox installation directory to a more suitable place is often more important. I have done some preliminary work for making the installation and login process work even when /scratchbox doesn't exist outside the sandbox; the work should be fairly simple to complete. A bigger problem (from my perspective) is the fact that Scratchbox can only be built directly to its installation directory. The tools fail to configure and/or build when things are not in correct places. I worked on this problem last year, but in the end it seemed next to impossible to fix--I don't remember the specific problems anymore. This problem could also be solved by building most of the tools inside the sandbox (like sb-perl-devkit and sb-toolchains are built), but then we'd also have to build all libraries and tools that are used during the build (i.e. Linux from scratch). Using autotools for building Scratchbox would be a bit pointless because the Scratchbox build procedure is not something automake or autoconf solve. Scratchbox is mostly just a set of upstream packages that already have autotools-based build systems; we just have to build them with correct settings (and patches) in the correct order. We use the GAR system[1] which is specifically designed for this. (GAR is a bit messy because it uses make; I'd one day like to replace it with a scons[2]-based build system...) [1] http://www.lnx-bbc.org/garchitecture.html [2] http://www.scons.org/ We (Lauri Leukkunen, Veli Mankinen and myself) have plans[3] for a complete redesign of Scratchbox which (among other things) solves all of the problems you mentioned. We're hoping to write a more elaborate Scratchbox 2.0 design document in near future. But any help in improving the existing versions is naturally welcome. :) [3] http://scratchbox.org/~tsavola/sb2-outline.txt I'm posting this message to scratchbox-devel so that we can continue the discussion on a more suitable mailing list. timo _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
