RE: [Axiom-developer] RE: cross-compiling Axiom

[Gabriel Dos Reis]

On Tue, 5 Sep 2006, Bill Page wrote:

| 1) Why should we want Axiom to be cross-compiled?

Because I believe that making Axiom more accessible is a very
important issue for Axiom.  You believe that people can just go
apt-get and voilà.  I highly suspect your view is right for a
very restricted class of people.

One way of making Axiom accessible is by "convincing" popular
linux distros to bundle it with their packages.

| I think there are many more important issues to address.

that is your belief.

I however agree there are other important issues to address. At the
moment, I don't believe they are more important that "getting Axiom to
the masses".

[...]

| I have explained and so had David Mentre and a few other people
| on this list.

David's message (from April) got an answer from Benjamin.
How many other people on this list?  Please be specific.

| > I've offered examples.  You either dismiss them, or turn around.
|
| I have explained in detail why I dismiss them. In each case they
| do not satisfy even your own definition of cross-compilation
| when earlier you quoted:
|
| http://en.wikipedia.org/wiki/Cross-compiling
|
| in a response to Tim.
|
| "Compiling a program takes place by running a compiler on the
| build platform. The compiled program will run on the host platform.
| Usually these two are the same; if they are different, the process
| is called cross-compilation."
|
| In the SBCL example, the program compilation is not complete until
| after extensive initialization and the final 'save-system' which must
| be done on the target system. The target is integrally involved in
| the process.

but that does not disqualify it from being a cross-compilation.  If
you follow a cross-compilation of GCC step by step, you'll notice
that, in effect we do similar things except that it is less
noticeable.  The "save image" step in the SBCL case, corresponds to
the "linking step" of GCC and its dependence on libgcc (except that
the linker does not run the executable but in needs to be a cross).
The save image step can be made by a simple "loader-n-saver" that
indeed need to run on the target but that loader-n-saver does not need
to be a full-implementation (therefore small) and get to run in a
simulator.  That is cheap.  You would have done all the work on the
host and the tiny tricky on the simulated target.  You would have
produced the whole suite without having access to the target.  That is
cross-compilation.

| > And now, you complain I'm non-analytical and confrontational.
| > That IS disappointing.
|
| I said that because you have never answered any of my questions
| in this thread.

That simply is untrue.

| You have only been issuing "challenges".

No; I've just been amazed how negative you want this stuff to be:
"it is impossible to do, and you speak of doing it, then you must not
understand it, and if you do understand it, then it is not important".

Now, if that is constructrive, then I hereby apply for the rank of
"arm-chair contributor" :-)

[...]

| When Axiom is built using GCL, gcc becomes an integral part of
| Axiom. Axiom cannot run without it. gcc is called every time you
| define a function. So to run Axiom you must provide the gcc
| environment.

No, I do not need to provide GCC environment.  I just need to make
sure that the right GCC is called.  GCL does not provide GCC.  It just
assumes GCC exists.

| If you have the gcc environment, then GCL and Axiom
| can be built on the target environment. 2) What is the point of
| "jumping-through-hoops" to try to arrange that some part of the
| build can take place on a host environment separate from the
| target when in the end the target must have the same environment,
| must be sufficiently powerful to run Axiom and must in any case
| be involved in the creation of the resulting program?

but, you know that is not the case.  So, you want me to answer a
question that is at best a mischaracterization to begin with?

sigh.

-- Gaby