Re: Suggestions for how ARM Ltd could help Debian?
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
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! :)