Re: atlasv3.1.4D

[R Clint Whaley <rwhaley@cs.utk.edu>]

Camm,

>Greetings!  I just had a question regarding the preparation of the new
>source for a distributed package.  Clint -- is there any way to
>instruct the build procedure to compile in the defaults for a
>particular machine, but then not to execute/time any code containing
>those defaults?  I.e.  can we build some sort of cross-compilation
>capability into atlas?  Or is it there already?  I know this does not
>necessarily produce the optimal binary, but it would probably make a
>good approximation, when can then be refined by the interested user by
>rebuilding the package on the box in question.

There is presently no way to shut off all timings.  It's been on my
to do list for some time now (mainly to speedup install times), but
it is obvious I will not get around to it this release.  Even if we
had this, I don't think it would do what you want: build a complete
lib for a machine for which you have no access.  The defaults don't
specify *everything*, just some of the more standard and time-
consuming things.  Almost every architecture still needs some timings
to complete the install . . .

ATLAS has built-in functionality for cross-compilation, assuming the
compiling and target machines are mutually rsh-able, and share a file
system.  I think it is viable to remove the restriction that they
share a filesystem, but I haven't gotten around to doing so yet . . .

If cross-compiling is all you want, just answer yes to that question
during config.  The next developer release has some special code in
for when the NFS server is overloaded or there are clock problems
(essentially, it tolerates delays in file creation on target machine
before it appears on the cross-compiling machine), so if your cross-
compilation dies looking for a file that is already there, the next
developer release should fix things . . .

Cheers,
Clint