Use C-version of SLALIB?

[robert.desonia@…]

For rel2, we used the Fortran version of SLALIB, but a SLALIB is available, so
the README claims. Do you of any reason we shouldn't petition for getting the
C version from the author, e.g., known performance, maintenance, accuracy
issues?

Does IfA have the C version already?

A C version would remove any future C<->Fortran call portability problems,
which is really the only reason I bring up this library replacement option.

-rdd

[eugene]

We would definitely prefer moving to the C version of the library. There are
two major issues:

1) licensing. unfortunately, the C version has a more restrictive license than
the fortran version. Still, it is free to professional astronomers, so this is
probably not a major issue.

2) precision. the C standard has a more limited required minimum number of bits
for a double than fortran, even though the normal C compiler actually delivers
the same number of bits. Pat gets around this by using two doubles in some
cases where one was used in the fortran version.

In the long run, we are evaluating our general use of SLALIB. There are only a
limited number of places we are calling it and the underlying functions are not
so fancy. We may eventually just recode those algortithms. For now, I would
say: go with the C library.

[Eric.VanAlst@…]

During MHPCC/IfA meeting on 2/10/05 a decision not to use SLA C version because
of licensing and algorithms was made. Should this bug be closed?

[eugene]

We need to have buy-in here (IfA) from a few parties to drop SLALib support
completely. In the interim, the solution of bundling the fortran versions with
the code is sufficient. Unless something surprising happens, we will not need C
Slalib support.

[Paul Price]

We are removing slalib completely.