5.1 General FAQs

For FAQs specifically about installation, see the next section, and for quite detailed FAQs about the various ways that state is held in the starconf system, see Section 5.3.

In the examples below, the installation location (that is, STARCONF_DEFAULT_PREFIX) is written as /local-star, and the example component is usually cpt.

How do I control which compiler and compiler options I use?

You can control the compiler at configure time by specifying the variable F77, FC, CC or CXX, as appropriate; and you add compiler options with the FFLAGS, FCFLAGS or CFLAGS variables. For details and warnings, see Section 2.1.5.

I've just been told ``make: *** No rule to make target `/local-star/manifests/cpt', needed by `world'. Stop. What's wrong?

The component cpt has been referred to in a dependency, but the Makefile.dependencies file has no knowledge of it. Whoever added the cpt component forgot to do the final step mentioned in Section 4.7, so you should do that now.

Why does make world not do anything?

The make world build works by comparing timestamps of the installed files in the manifests directory -- that is, in something like /local-star/manifests, outside of the build tree. It only checks whether each component was installed after each of the components it depends on. If you wish to use this to (rebuild and) reinstall a given component, then simply delete the manifest file for the component in question and re-run make world.

Alternatively, make in the top-level checkout directory will recurse, and invoke make all in each of its children, and thus bring the whole tree up to date.

You can check the default installation location -- shown as /local-star above -- with ./starconf-status --show STARCONF_DEFAULT_PREFIX

Also, make world only makes those targets listed in the variable ALL_TARGETS within the top-level Makefile. Thus if the component you're interested in isn't there, nor required by something that is there and that will be rebuilt, nothing will happen. See also Section 4.7.

See Section 5.3 for a few more remarks about state.

I've updated my checkout of a component. How do I best update the installation of it?

The most straightforward way is to change to the directory in question, and do ./configure; make; make install there.

Alternatively, you can stay in the top-level directory, delete the component's manifest file, rm /local-star/manifests/cpt, and remake it: make /local-star/manifests/cpt.

Actually, the component is one of the buildsupport tools. Is that different?

Yes. The best way is update your checkout of the component in question, then run ./bootstrap --buildsupport in the top level of the checkout. When the bootstrap script is run in this mode, it always deletes any buildsupport manifests, to ensure that the buildsupport tools are always rebuilt if updated.

It's best to avoid the ./configure; make; make install route described in the last item. Some of the buildsupport tools need special handling, and the ./bootstrap script knows how to do that.

I've updated my checkout and a large number of components were updated (or I'm paranoid). What's the best way to remake absolutely everything that needs it?

Just doing make would remake everything that needs remaking, but wouldn't install it. The command make world wouldn't work either, because that only works with the dependencies between manifest files -- this is the way that the Makefile.dependencies file expresses the dependencies of components on each other.

The best way to do this is as follows. After your update, and while in the top-level directory, do

% rm /local-star/manifests/*
% make buildsupport
% make world

That is, you delete all the manifests, and remake them. This does a make; make install in each component directory, and that step handles any files that were updated.

What's the best way to generate files at build time?

Look at the Makefile.am for the prm component. It's a good example of using noinst_ tools, the Fortran preprocessor, and ./configure variables in a reasonably tidy way.

I want to do odd things at clean/distribution time. How?

Odder than what is described in Section 4.3?

Automake also has support for extending what is cleaned and what is included in the distribution, though this does not have to be as elaborate as the support for extended installation above. See the documentation on CLEANFILES and EXTRA_DIST in the Automake manual.

I want to incorporate an external package which already has a configuration system. How?

This is `thirdparty code': see Section 4.5 for several examples.

How do I write portable Makefiles and shell scripts?

The autoconf manual has a very useful collection of portability advice in its section manual Portable Shell Programming. Also, the Single Unix Specification, version 3 provides standardised specifications of the behaviour of Unix library functions and system utilities. The Single Unix core specification is identical to POSIX.3 (IEEE Std 1003.1) and ISO/IEC 9945:2003.

I've just been told that libtool is ``unable to infer tagged configuration''. What on earth is that supposed to mean?

I'm not sure what this is supposed to mean exactly, but what it seems to mean in practice is that libtool has become terribly confused about your compiler. Very probably, you forced ./configure to use a particular compiler by specifying one of the F77, FC or CC environment variables at configure time. You may have forgotten that you have that variable set.

Alternatively, you may be unaware that that variable is set: a known manifestation of this problem is that the IRAF startup script sets F77 to be an IRAF-specific script, which works OK from the command-line (given that you want to use IRAF), but which leaves libtool in a confused heap.

This problem has also been spotted in the form libtool: compile: specify a tag with `--tag', with apparently the same cause.

See Section 2.1.5 for more discussion of these variables.

It's all going horribly wrong. Help!

Things to think about:

1. Are there some stray environment variables? Environment variables such as F77 or CC influence the compilers chosen at configure time, as discussed in Section 2.1.5. There is a particular problem with the IRAF startup script often sourced from the .login file: see item `I've just been told that libtool is ``unable to infer tagged configuration''. What on earth is that supposed to mean?'.
2. Are the buildsupport tools up to date? This is fairly unlikely (once the build system becomes a production system), but might be worth checking. See Section 3.5.
3. Think how happy you are that life has been good to you so far.