On Thu, 18 Jun 2009, Tim Jenness wrote:
> Thinking about things that need to be in place for the nanahope release in
> July. I can think of the following things that are being worked on or
> problematic:
>
> - vtk no longer builds on x86_64 Mac OSX because it keeps finding the native
> Tcl/Tk frameworks instead of
> finding the starlink tcl libraries. There are updates in the repository
> submodules that are not synced
> to the supermodule so I'm not sure whether this needs a local fix.
>
> [ 87%] Building CXX object
> Rendering/CMakeFiles/vtkRenderingTCL.dir/vtkRenderingTCLInit.o
> Linking CXX shared library ../bin/libvtkRenderingTCL.dylib
> ld warning: in
> /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks//tk.framework/tk,
> missing required architecture x86_64 in file
>
> - Norman may or may not come through with the autotools update but I'm
> thinking probably not in time for
> nanahope
>
> - on leopard the default build generates incorrect libtool files for the
> fortran section (it's an
> issue with -nostdlib). This may be a g95 vs gfortran linking issue or maybe
> a leopard vs tiger issue. I haven't
> tried building 32-bit with g95 on my leopard system.
>
> - Not sure if Brad is intending to do an automated perl build for this release
> using shipwright
> or whether he is going to build for all architectures manually.
>
> - SAMP support in GAIA
>
> - David's CUPID VO STC-S work seems to be ready.
>
> - I think GAIA-VO needs more testing by people before the release. Can people
> try it and see whether
> it works for them?
>
> - Peter: Will GAIA visualisation of STC-S catalogues be ready at least in a
> demo mode? Or would you prefer to punt to August? I'd like to have some
> debugging time before you turn into a pumpkin.
>
> - Sam Hart has requested that we ship the linux builds with Java 1.6 so that
> he can begin the process
> of migrating the OT now that JSky requires v1.6.
Distributing a 1.6 JRE (or even JDK) is not problematic. Distributing
a starjava set which has been built using a 1.6 JDK may be somewhat
problematic, in that it means anybody wanting to use the
distributed jar files must be running 1.6, and not everybody is.
There's no reason in principle why you can't distribute a 1.6 J{RE,DK}
with a starjava set built using 1.5 (or 1.4), but I don't know if that's
what the current build/distribute setup is going to do.
The relevant facts are: it's all backwardly but not forwardly compatible,
so that a J{RE,DK} of version X can work with any classes/jar files
built using versions <=X, but not >X.
So, I'd prefer to ensure that the starjava build is done using 1.5
(or 1.4). I don't necessarily demand this, but if you're going to
do different I'd like to know about it and make sure the implications
are clear.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|