SMURF make_params doesn't work on clean build

[sfgraves]

On a completely clean build, the SMURF file 'params.tex', generated by make_pardocs is empty. This file should contain the prolat-generated documentation of all the smurf dimmconfig parameters.

This problem occurs on both OSX (built by @sfsgraves) and on Linux (built by @grahambell ). I'd run across the problem previously but @dsberry couldn't reproduce it so I assumed it was something weird in my setup.

The file 'make_pardocs.in' expects the make system to replace @PROLAT@ with the path to the prolat binary. In this build however it has just been replaced with the word 'prolat'.

[timj]

STAR_CHECK_PROGS will default to not including a path in a clean build because it doesn't find the tools when configure is first run. This is meant to work on the understanding that they will be in your path. For prolat there is the wrinkle that SST is not in the path. This is why configure.ac uses:

STAR_CHECK_PROGS(prolat, sst)

This is meant to handle the case for Starlink apps but I'm not sure what it's meant to do. @pwdraper or @nxg might remember.

[pwdraper]

The behaviour of STAR_CHECK_PROGS is broken as SST is really a configure dependency. The way people (mainly David) work around this is by adding $STARLINK/bin/sst to the PATH before proxxx tasks are invoked. See the sections in Makefile.am of atools that handle the help file processing for instance.

[timj]

Could the two argument version of the macro default the result to be $STARCONF_DEFAULT_STARLINK/bin/xxx rather than defaulting to xxx if the executable can not be found? That would be more in line with expectation.

[dsberry]

The scheme used by atools is recommended by Norman in the docs. See "Some components build their documentation...." paragraph at the end of:

http://www.astro.gla.ac.uk/~norman/star/ssn78/ssn78.htx/N-x1a1b14.html#xref_macro-check-progs

David

[nxg]

There's an impressive number of variants of ‘this is not ideal, but...’ in that document. I fear I can't add much to the present discussion.

I see that the advice at the end includes ‘it depends on undocumented (but unlikely to change in practice) knowledge of how the sst component is installed, and it is possible to think of convoluted installation schemes which might trip this up.’ Has this happened in fact?

[timj]

But we are talking about the case where SST has not been installed yet. The hack works for the case where it had been installed so we are talking about whether the fallback behavior should change for this case.

[dsberry]

Given that Norman's comments for STAR_CHECK_PROGS makes it all look rather fragile, I've taken the safe and quick route of changing make_pardocs.in to add @STARLINK@/bin/sst to the PATH before using prolat. See 589d697c1

[sfgraves]

Thanks David!