On Mon, 19 Dec 2005, Mark Taylor wrote:
> On Mon, 19 Dec 2005, Tim Jenness wrote:
>
>>> Apart from a couple of facilities dropped because they're not in
>>> the new interface, as far as I can see everything seems to work OK,
>>
>> Which ones? The CMP routines or the datGetNx/datPutNx routines?
>
> No, neither of those are (or have ever been) in JNIHDS.
> Just datWhere and some relating to locator constants
> (DAT__NOLOC and DAT__ROOT) I think.
Okay. Noone used datWhere and it exposed HDS internals. We'll add it back
if there is demand.
>
>>> The build still links against libcnf because that's what star/bin/hds_link
>>> andn star/bin/err_link do.
>>>
>>
>> CNF isn't really a problem but could be restricted to just the Fortran
>> wrappers (and have a libhdsf like there is a libemsf). It's ems not err
>> that is used and that can't be removed (it's buried deep) unless you do
>
> I'm running err_link because I explicitly use errMark(), errLoad(),
> errFlush(), errRlse() to turn HDS errors into java exceptions,
> which seemed like the sensible way to do it.
If you replace the err calls with the ems equivalents then lives will be
made easier since MERS is fortran but EMS is C only.
> I presume you're talking about modifying HDS so it has pluggable error
> handling. I'm not quite sure how that would be done but can try to
> work with it if it is. As I say, I do turn non-zero status returns
> into exceptions, but it's done separately in the JNIHDS and JNIAST packages
> (see HDSCALL and ASTCALL macros if you're interested), there isn't an
> off the shelf library routine for it.
Just changing the linking. AST does that with its ability to link against
different error libraries. I could add a -myerr option to hds_link that
would simply stop it doing the ems_link and allow you to insert private
ems functions.
If you don't mind the ems dependency (and you get rid of ERR) then I don't
think there's a need for it.
>
>> If it makes life easier I can make "hds_link Conly" (cf ems_link) only
>> link in the C routines and separate the fortran interface into a separate
>> library. (I was goiong to do that when I had finished the Nx routines but
>> this seems to be higher priority).
>
> This is really between you and Peter - it doesn't make any difference
> to me how it links, but it may make the builds on wacky OSs easier
> if you can extirpate all the fortran references.
It would be a godsend to remove fortran from HDS :-)
I'll add it and I'm sure Peter would appreciate a switch to EMS when he
builds the native Windows version.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|