Greetings, all.
You might want to have a go with the CVS changes. Don't get too
excited -- it's not finished yet -- but it's in a state where other
folk can look at it, and possibly start working on it.
The following Works For Me:
% cvs -d :ext:[log in to unmask]:/cvs checkout .
% unset STARLINK
% export STARCONF_DEFAULT_STARLINK=/export3/sun
% export STARCONF_DEFAULT_PREFIX=/export3/sun
% ls /export3/sun # or whereever
ls: /export3/sun: No such file or directory
% PATH=/export3/sun/bin:/export3/sun/buildsupport/bin:$PATH
# put /export3/sun/{,buildsupport/}bin in the path, and make sure that
# there are NO Starlink binary directories in the path
% which autoconf
/usr/bin/autoconf
% autoconf --version # should work with any or no preexisting autoconf
Autoconf version 2.13
% hash -r # forget the old location of autoconf
% ./bootstrap
... a few harmless warnings, and miscellaneous other chatter
... takes quite a while
% which autoconf
/export3/sun/buildsupport/bin/autoconf
% autoconf --version
autoconf (GNU Autoconf) 2.59
...
% ./configure -C # -C means caching results
... mucho blah-blah-blah
% make
... etc
% ls /export3/sun/manifests
adam automake ems hlp messgen par sae star2html task
ams chr fio lex messys parsecon sla starconf
atimer cnf hds libtool misc pcs sock string
autoconf dtask hdspar mers msp psx sst subpar
%
%
%
% # now AST
%
% cd /tmp/norman
% cvs -d :ext:[log in to unmask]:/cvs checkout -r dev-nxg-20031121-autoconfing libraries/ast
% cd libraries/ast
% ./bootstrap
% ./configure -C
... blah
% make
... still more blah
% make install-manifest
% ls /export3/sun/manifests/
adam autoconf dtask hdspar mers msp psx sst subpar
ams automake ems hlp messgen par sae star2html task
ast chr fio lex messys parsecon sla starconf
atimer cnf hds libtool misc pcs sock string
%
This now includes star2html (as of this morning), so that AST is building
entirely from within the source tree.
Things that don't work:
* This works on ix86, but I haven't yet tested it on any other platform,
such as a Sun. There shouldn't be any major problem with that, but I
haven't, for example, looked at the business of the extra link flags
that Suns sometimes need, and I'm not sure if automake's magic covers
this already. This does not mean I'd have to special-case anything,
but I probably haven't yet added in the generic thing which just
takes care of that.
* The collection of environment variables at the top is unattractive.
There is a compromise here between being able to control the build
environment reproducibly, and intelligibly, and flexibly, both at
bootstrap time (when nothing at all is already built, which would be
the case for the nightly build, for example) and when you're working
on a component within the context of a mostly built Starlink tree.
I'm not positive I've hit the right spot, and so if anyone has any
particularly strong feelings about this I'd like to hear them.
* I haven't really had a chance to test star2html. Also, I think
there's something vaguely wierd about the way the documentation's
being built, which I haven't pinned down.
* I've generally checked in test code from the original sources,
where I was aware such code existed, but I haven't done anything
with that code, such as plug it in to the simple regression-test
harnesses that automake provides.
So, what now?
This isn't tagged, and I'm not sure what to tag it. The description of
tagging at <http://wiki.starlink.ac.uk/twiki/bin/view/Starlink/CvsTagging>
doesn't really seem to cover it unambiguously. Should I call this the
first version of the Spring/Summer release, and thus something like r1-b1?
Or should we go with the release numbers that were mentioned a little
while ago (I've forgotten the location of the file mentioned then which
contains notes on every Starlink release for the last 25 years, in which
we're up to release 600 or thereabouts). Mark's discussion of the tags
file on the CvsTagging page seems to be specific to Java, purely because
it's located within the java/ part of the tree. Ummmm: any thoughts
-- 'flu symptoms have befuddled me?
At any rate, I think this is now in a state where DavidB could take a look
at the AST stuff, and probably merge it onto the trunk. Since David is
the `codeline owner' for AST, it should be him who does the merge rather
than me, though there's a link with the `docking line' pattern mentioned
on <http://wiki.starlink.ac.uk/twiki/bin/view/Starlink/BranchingPolicy>.
David: given that you're up for doing the merge, here's how.
You check out a copy of the branch I've been working on, namely
`dev-nxg-20031121-autoconfing', and you get that with the checkout
command mentioned above. After that, you should see something like
this:
ptolemy:ast> cvs status -v lutmap.c
===================================================================
File: lutmap.c Status: Up-to-date
Working revision: 1.4
Repository revision: 1.4 /cvs/libraries/ast/lutmap.c,v
Sticky Tag: dev-nxg-20031121-autoconfing (branch: 1.4.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
dev-nxg-20031121-autoconfing (branch: 1.4.2)
bp-dev-nxg-20031121-autoconfing (revision: 1.4)
ast-3-1-0-import (revision: 1.4)
10-Jan-2002-13-59 (revision: 1.3)
04-Sep-2001-11-08 (revision: 1.3)
04-Oct-2000-09-26 (revision: 1.3)
The `Sticky Tag' confirms that the file you're looking at is on the
branch in question, and this will be the case for all the files in
this directory. Check that you're happy with what's there, and
make any changes you like, committing them afterwards.
At that point, you're ready to merge this branch on to the trunk.
Go to an up-to-date checkout of the trunk -- which you get as usual,
with something like
cvs -d :ext:[log in to unmask]:/cvs checkout libraries/ast
omitting the -r option that was specified before. Now you can merge
from the branch:
cd libraries/ast
cvs update -j dev-nxg-20031121-autoconfing
Thus you give the name of the _branch_ as the argument to the -j
option, and this merges the _head_ of this branch with the code in the
current directory, including all the changes that have been made on
that branch. It's possible to give the -j option on the checkout
command, to do both operations together.
At this point, immediately go back to the checkout of the branch, and, in
that directory, tag it with the name of the branch followed by `-MERGED':
cvs tag dev-nxg-20031121-autoconfing-MERGED
That does two things: it indicates that this branch has indeed been
merged somewhere; and makes available a tag which logs the precise
versions which were merged. If it becomes necessary to do more work on
that branch later, and then merge the branch a second time, then this
tag can be used to say `merge all the changes between that branch and
the head'. That's unlikely to be the case for this particular branch,
but it's probably a good habit to use. See the section on `Branching
and Merging' in the CVS manual.
Now go back to the checkout of the trunk. If there were any conflicts
when you did the merge, this is the time to sort them out, and check that
everything still works to your satisfaction. Then commit the changes
onto the trunk, with the usual `cvs commit ...' command.
That's it -- AST is now autoconfed, and the branch I was working can be
forgotten.
The next things to do, either at the weekend or on Monday, are as follows:
1. I should make a start at documenting this. I don't plan to produce
anything terribly elaborate, but enough for other folk to start
working with the modified tools.
2. I'll try building this on one of the Suns at RAL, and possibly one
of the alphas, and see what happens. It might just work as it is,
in which case I'll be very pleased.
3. I'll start on ccdpack.
I think I should do those in that order -- does anyone disagree?
After I've done that, and after David's done the AST merge to general
satisfaction, I think it will then be the time to declare the repository
in place and live, and Brad, for example, might want to start merging
his OS X changes.
I don't think this project will be finished at that point, since
there will surely be a variety of places where I've unwittingly used
Linux-specific behaviour, or am generating a wrong Makefile rule, but
they can be dealt with as they emerge.
As a final point, I'm starting to worry that having generated files
checked in might become rather a nuisance. This is because things end
up configured slightly differently when they're configured as part of
a complete tree -- for example at bootstrap time -- and when they're
configured more in isolation. The differences are trivial, to do with
the location of helper files, and I mention it only to say that I know
about this apparently odd behaviour, so don't worry if things like
Makefile.in or configure seem to change unexpectedly. Since you _have_
to use the version of automake which is in the repository, version number
1.8.2-starlink, the original argument for checking in generated sources
is a lot less persuasive. It doesn't immediately follow that checking
these in is a bad thing, but it becomes open for discussion more.
Whew. Now for a rest.
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
