Greetings, all.
DavidB mailed me with a very useful distillation of issues concerning
the autoconfing of AST, some of which are of relevance beyond AST,
and deserve more general discussion. The following is the list, plus
my initial responses, and minus some AST-specific issues.
Some of my responses are effectively defences of the way that
automake/libtool does things, in opposition to the way we've
traditionally organised it, and thus defences of the idea that we
should make our stuff look as conventional in its installation as
possible.
There's no rush on this, since (I recall) both Peter and Mark are away
this week, and I very probably won't be in until Wednesday (not least
because I understand that my machine died at the end of last week
and will take a couple of days to resurrect -- so I'm getting Debian
something-or-other). This also means I haven't been able to check a
couple of points in what I write below.
> 4) Should sharable libraries go in star/share rather than star/lib?
I think not. We have put them there in the past, when makefiles
installed them at all, but this is definitely non-standard (I'll be
able to find chapter and verse if anyone wants, but I _think_ that this
is part of both the Unix Filesystem Standard and POSIX): share/ is for
platform-independent data files -- ie, text.
That definition, incidentally, covers the material we currently put
into /star/help, /star/docs, and possibly /star/etc (I think etc/
directories are supposed to be for host-specific configuration files).
Is there a case for putting the contents of these under share/
instead, apart from the problem of modifying those libraries which look
for things in $STARLINK/{help,docs,etc} specifically? Are there _any_
non-Starlink programs which use these?
> 6) Do we need to install 46 libraries when 9 used to do?
The generated Makefile.in installs the .a static library, plus the
(small) .la `libtool library', plus the .so sharable library and its
.so.0 and .so.0.0.0 links. I think the .la file is required if you
want to link against these using libtool.
Thus the question is `do we want to install shared libraries?'. I
think `yes', because disk space is cheap and they'll probably be
useful to folk. Are there any disadvantages?
> 8) Fortran docs need to be changed to do away with references to dev
> scripts such ast ast_dev and use -I option instead.
The *_dev scripts generally set up local links to include files (do
any of them do anything else?). This is probably redundant, since I'd
imagine that any important Fortran compiler supports the -I option.
If we ever were to come across a Fortran compiler which doesn't support
the -I option, then it shouldn't be hard to work round it.
> 9) If we decide to stick with putting -L$STAR/lib inside the link script,
> then we need to change the docs appropriately.
I (indirectly) altered the semantics of the ast_link script, as it
now includes -L<install-prefix>/lib, which David reports was excluded
from *_link scripts as the result of a long-ago programmers' decision
(I'd need to check precisely why this appears, but it doesn't change
the overall point). Is this a problem? I don't think so, but if the
decision was taken while I was in Starlink I've completely forgotten
it, and so can't remember the reason for it.
The more general point which David mentions in this and point 8 is that
various docs will surely have to be changed to remove mentions of *_dev
and include mentions of -I and -L.
> 10) We need an uninstall utility
A utility, yes, but I don't think it has to be part of the makefile.
a) An uninstall script doesn't have to be much beyond
rm `grep '^/' $STARLINK/manifests/ast`
(or whatever package it is you want to uninstall). Of course, this
could be put into the generated Makefile.in if that was useful.
b) Isn't this part of the larger question of package management? In
other words, would this question disappear if we started creating, and
recommending the use of, RPMs or Debian PKGs?
> 11) We need a makefile target equivalent to the old "./mk check".
>
> 12) Need to add a test to the makefile. I notice that
>
> http://www.astro.gla.ac.uk/users/norman/star/ssn78/ssn78.htx/N-a4b2.html
>
> says that "make check" does the test *before* the component is installed.
> So it will not confirm that the installation has been successful. Which is
> a shame since that is an important thing which needs to be checked
> somehow.
`./mk check' was a test that the package had been correctly installed.
The `make check' described in SSN/78 is really a regression test, and
thus run by a developer or an inquisitive or bug-searching user. Do we
need a separate, and standard, installation test? David thinks yes,
above; I think no; though we haven't discussed this and I don't believe
either position is particularly entrenched. If the installation fails
(which happens rarely), that's a straightforward bug, which one presumes
the developer would spot as part of preparing a component for release.
Also, if `make install-manifest' goes wrong, then the user will presumably
spot that. What is the installation test actually checking, by the way?
> 13) [AST distribution problems]
Not a terribly general issue, but there are a couple of gotchas in the
way that the AST distribution tarball is rolled. I've arranged with
David that I'll sort these out after he's committed his merging of
AST, but this is to note that these do exist, and probably exist to a
greater or lesser degree in other components. So this is just to note
that I know about these, and they're on the list.
And an extra one to David's list:
14) Should we preserve the distinction between `make install' and
`make install-manifest'?
That is, should I change it so that `make install' installs the
manifest as well? I'm inclined to do this, unless anyone can think of
a reason why this would be unhelpful.
See you,
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|
