On Wed, 26 Mar 2008, Malcolm J. Currie wrote:

> [cc'ed to Brad -- is it you who's responsible for building the
> distribution, Brad?]

yes.

>
> On 2008 Mar 26, at 16:15, Malcolm J. Currie wrote:
>
>> Please can you enlighten me regarding the libdir token used by libtool
>> etc.  I've searched through SSN/78 and it's not explained.  The
>> reason I
>> ask is because there are two IDL scripts in CONVERT that define a
>> LIB_NAME
>>
>> LIB_NAME = '@libdir@/@DLNAME@'
>>
>> using libdir.  The following error report indicate that libdir is
>> assigned to where Brad built the library, not where that's installed
>> locally.
>
> I _think_ that the underlying cause of this is that Brad (reasonably!)
> does a 'make prefix=/xxx install' when building the distribution, or
> something equivalent to that (is that correct, Brad?).

You're behind the times. The difference between puana and humu is that 
humu was intended to be completely relocatable after it has been built. 
This was the holy grail of starlink distributions in that people no longer 
need to download it and put the distribution in /star (usually requiring 
sysadmin access) but can plonk it on a data disk.

We do this by defining all paths in terms of the new $STARLINK_DIR 
environment variable. The humu build was done in a private build directory 
hence we are hitting problems with relocation issues that we did not quite 
sort before release (and no-one tried IDL).

I think we've made excellent progress in this attempt.

>
> The @libdir@ variable is one which is supposed to be finalised at
> installation time, not build time -- it's not supposed to be baked in
> to anything at build time, precisely so that one can do 'make prefix=/
> xxx install' which implicitly changes libdir to $prefix/lib.  However,
> it looks like write_ndf.pro has @libdir@ baked into it at build time,
> while set to a temporary location on Brad's machine.  [See Section
> 4.7.2 of the autoconf manual, which refers to section 7.2.5 of the GNU
> coding standards]
>
> Grepping the applications/ directory, it appears that only convert,

ack is your friend (cpan install App::Ack - it's great).

> dipso, gaia, sgmlkit, startcl and tsp  Makefile.am files refer to
> libdir at all, and it looks like we've got away with it in the other
> cases.

A quick ack of the source code tree indicates that only kappa 
lutedit.f (if KAPPA_DIR is undefined), sup_nametr.f and 
gks/base/gkdfop.F have /star embedded (I should use PSX_GETENV now or 
call ems1Starf and fix it to use STARLINK_DIR).

I also haven't worked out how ems1Starf works given it purports to check 
$INSTALL but I can't find the string INSTALL in the source code.

Looking at the 32-bit tar distribution there are quite a few scripts in 
the bin directory that have broken #! (eg ifd2star that needs the same fix 
used for lutedit.tcl) that we need to sort out for the next release. Also 
using this relocated release for building new applications does work but 
libtool complains that the libraries have moved (it was mainly done to 
help people run the software not build it - people who are building 
applications are expected to build their own tree from source).

PONGO may be broken after having a quick look at $STARLINK_DIR/star/pongo 
- I think it needs to use an environment variable.

>
> So what to do?  This surely isn't the only component which refers to a
> library -- what do other ones do?  Can IDL refer to an environment
> variable?  I forget whether $STARLINK is necessarily defined at run
> time.

We guarantee now that $STARLINK_DIR will be set.

IDL has a GETENV function

http://www.astro.umass.edu/~tangsk/documents/idl_html_help/G12.html

PS How are those autoconf patches coming along? :-)

-- 
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj