On Mon, 24 Jul 2017, David Berry wrote:
> On 22 July 2017 at 05:21, Graham Bell <[log in to unmask]> wrote:
> >> [...] the src/lib/*/jniast_libs.jar native files need to be recompiled and
> >> committed for all supported architectures.
> >
> >
> > Hello,
> >
> > I've done that for Linux and hopefully fixed the errors which were
> > preventing us compiling them on Mac OS X.
> >
> > The Starlink release build process (as on the wiki page "StarlinkRelease")
> > needs the update for astSlaAdd, astSpecAdd and astTimeAdd as otherwise an
> > error occurs at the build-native step due to the new nargs parameter not
> > being supplied. If you want to be able to run "ant ... test" with either
> > version of AST, we could just take away the two new "assertTrue(raised);"
> > lines from the test -- they check something that wasn't being tested before.
> >
> > Best regards,
> > Graham
>
> I'm not sure I understand. What is it that requires the new nargs
> parameters, and why are they required? What is the problem with just
> leaving jniast as it is? Just picking up one change from the current
> version of AST and ignoring all the countless other changes that have
> happened since the last rebuild of the native jniast libraries seems a
> bit odd.
I agree with David, this doesn't look right to me, though I don't
know what the actual changes in AST requiring this are.
In any case, it's not enough to just rebuild and commit
jniast/src/lib/amd64/jniast_libs.jar, all the other architectures
(i386, ppc, sparc, x86, x86_64) have to be rebuilt as well
otherwise we have an inconsistent repository.
It seems to me that the right thing to do here is just to remove
the build-native step from the starlink build process, and back
out of all these JNIAST changes. The build-native step is not
intended to be done during a normal build from source, which is
why the native libraries are checked in to the repository.
The alternative is to make a proper update at least of all the
built native libraries and commit them back to the repository,
preferably alongside a full review and update of what's changed
since the last build-native was done, at least to check that
recent AST updates won't have broken anything. On the other
hand after so long in java-land I'm pretty ignorant about the
requirements for platform-specific code, so it's possible that
I'm missing some essential reason why build-native has to get
done in a starlink release
Since SPLAT is the thing most affected here Peter might have
relevant opinions.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
|