JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for STARDEV Archives


STARDEV Archives

STARDEV Archives


STARDEV@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

STARDEV Home

STARDEV Home

STARDEV  February 2004

STARDEV February 2004

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: now try it out

From:

"Giaretta, DL (David)" <[log in to unmask]>

Reply-To:

Starlink development <[log in to unmask]>

Date:

Sat, 21 Feb 2004 23:18:32 -0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (265 lines)

 Norman

Excellent! Let's give it a go.

...David

-----Original Message-----
From: Starlink development
To: [log in to unmask]
Sent: 20/02/2004 18:18
Subject: CVS: now try it out

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]

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
2004
April 2003
2003


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager