ext Peter Naulls wrote:
You could argue that patching these packages/encouraging the maintainers to make them cross compile might be rather less effort (and pay dividends later) than building a system like scratchbox.
Well, this might be true. Or then it might not. I don't know, and based on the evaluation of our options, back when we decided to give scratchbox a shot, we considered our chances of making scratchbox work better than taking the route of fixing or encouraging others to fix all those components we are interested in. I'm not saying all of them are broken (wrt. cross-compiling) but a substantial number are.
If we were right or wrong is a bit irrelevant to us now. Scratchbox works well enough for our needs currently and its maintenance isn't prohibitively time consuming. If someone provides a better solution, good for them. We'll probably be among the first to try it out.
Finally, as has been pointed out, the ARM build machines are doing ok as is, and aren't in desperate need of lots of CPU power. And you still need to have an ARM machine to debug things on if things go wrong. The answer might be different for the 68K port, however.
We are really looking at building the whole distribution (not the complete Debian, only those parts we want) as fast as possible (talking about minutes, not days). We'd need one heck of a cluster of ARM hardware to do it within our requirements. The reasons for this (cross-compiling everything at once and the performance requirement) are many.
My main problem with it is that it suggests that cross compiling is hard, when in most cases, it isn't, and the methods for doing it are quite straight forward. In other words, it doesn't seem like it has fully explored or discussed the alternatives fairly.
I think you are now focusing way too much on the "cpu-transparency" feature. Scratchbox provides a sandbox inside of which you can be assured that no unwanted headers or libraries are used in the compilation. This is pretty standard stuff when building a complete distribution from scratch. We need to put in a lot of tools since we want to cross-compile it and the host tools are not available in the chrooted environment. Scratchbox isn't just for compiling Debian. It can and is being used to build custom distributions as well.
It also solves the problem with configure scripts. It has many other nifty little tricks like execution redirection: you can specify (in an environment variable) pairs of absolute paths, when someone tries to exec the first, the latter is actually run; this redirection ability has allowed us to preserve /bin directory inside scratchbox for target binaries without ending up running all shell scripts on the ARM box. I think you've solved the configure script issue differently, I certainly can live with that.
If your argument against Scratchbox is really that you don't like how we consider some cross-compilation problems to be laborious to fix, then you are of course entitled to your opinion, but I reserve the right to have my own ideas of what is troublesome and what isn't. Making Scratchbox has been a lot of fun, a lot more fun than fixing the configure scripts anyway, IMHO.
In the end I don't think there is much to argue about here. If you don't like scratchbox for some reason, fine. You really don't have to use it. If you think some language on the scratchbox.org site is inaccurate, well... We've never intentionally attempted to make anybody else look bad. How you get offended when, according to you, we are expressing our own incompetence wrt. cross-compiling is beyond me. I fail to understand how it would be scratchbox project's job to explain what alternatives exist for each particular developer's situation. If the developer is interested in cross-compilation for ARM he probably has the experience to make his own decisions. If not, then at least scratchbox gives him something to help him along the road.
Ah well. This is the last from me concerning this thread on this list. Merry Christmas to all! :)
/lauri