STAR_CHECK_PROGS(progs-to-check-for, [package=''])
Note: The functionality of this macro is very likely to change.
For each of the programs in
PROGS-TO-CHECK-FOR, define a variable whose
name is the upcased version of the program name, and whose
value is the full path to that program, or the expected
installation location of that program if no absolute path
can be found. Because of this default behaviour, this
macro should _only_ be used for locating Starlink programs
such as messgen or alink, and not as a general replacement
for
AC_CHECK_PROG.
Any characters in the
program outside of the set of alphanumerics and
underscores are normalised to underscores.
The optional second argument gives the name of the package containing the program in question. Some packages install their binaries in package-specific directories, and this argument allows this macro to look there as well.
For example: STAR_CHECK_PROGS(messgen)
would define the variable MESSGEN to have the
full path to the messgen application.
Calls AC_SUBST and AC_ARG_VAR on the generated variable name.
This is the analogue of AC_CHECK_PROG,
except that: (1) the variable name defaults to the program
name, (2) if the program is not found, the variable value
is the program's name without any path at all.
The current value of the PATH variable is
augmented by the location of the binary installation
directory, using the current default value of the prefix
(not ideal, since this may in principle change when the
component being configured is installed, but it's the best
we can do at configure time); and by the
$STARLINK/bin directory.
If the program in question cannot be found, the the substitution variable is set to be the name of the program without any path, in the expectation or hope that the program will eventually end up in the path. This is not ideal, but it is the best that can be done in the important case where the program is being configured as part of bootstrapping build, and thus before any packages have been built and installed, so that there is in fact no installed program to be found. This heuristic will obviously fail when the program to be checked for is not in the path, and this will typically happen when the second `package' argument is non-null. The pattern to use in this case is as follows.
Some components build their documentation using the (now
deprecated) sst component. This uses the
per-package-dirs option, and so installs its
applications in a package-specific directory. You would
therefore check for the prolat tool (for
example) in configure.ac using
STAR_CHECK_PROGS(prolat,sst). If the
sst component is in fact installed, this
would substitute @PROLAT@ with the full path
to the application; but in a bootstrap build could do no
more than subsitute it with the bare program name
prolat, as described above. In order to use
this within a Makefile.am, you would have to
use a rule like
target: dependency
PATH=$$PATH:$(STARLINK)/bin/sst @PROLAT@ args...
PATH is temporarily augmented with
the installation location of the sst
component. This is pretty safe, because the
STARLINK Makefile variable is always present
and always substituted. Despite that, it is not ideal, since 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. Given that,
the only time this is likely to matter is during a
bootstrap build (at other times, prolat would
be installed already and so @PROLAT@ would be
substituted with a full path), so it is unlikely to be a
problem in practice.