D0 GROUP LEVEL3
ONLINE LESSONS

Episode I
Building a Working Area Using ctest

IMPORTANT NOTE : dOmino is now the interactive machine for Run II development.
 

IMPORTANT UPDATE : See the UPDATE for information which will clarify some confusion about ctest.

<d0mino> setup D0RunII t00.xx.00

The only way to know what the current release is, is to ask.  The L3 release co-ordinator is Kostas Papageorgiou  and he can tell you which release is current.

<d0mino> setup d0cvs // you might want to put this in your login file

<d0mino> setup n32

set directory to your local working area

<d0mino> cd ~cope/
    // the directory under which you will work

<d0mino> newrel -t t00.xx.00 txx
    //in this case, txx will become the release directory
    //the name is up to you, I like txx so that I can see at a glance which release I'm using.

<d0mino> ls txx // to see a directory listing

GNUmakefile  doc          lib          results      ups
bin          include      man          tmp

<d0mino> d0setwa

// d0setwa is the command which will set up your local variables for pointing to (among other things) the rcp database.  You must issue this command.

//if you want to build your own working package, the most convenient way to do that is with ctnewpkg.

<d0mino> ctnewpkg -h // to ask for help

Usage:  ctnewpkg [-huloibs] pkgname
       -h for help (this message)
       -u for updating an existing package
       -l to add instructions for building the library
       -o to add instructions for creating bare objects
       -d to add instructions for creating D0OM headers/objects
       -i to add instructions for integrated testing
       -b to add instructions for creating binaries
       -s to add instructions for installing scripts
       doc and version files are added automatically
       Existing files are never overwritten.

<d02ka> ctnewpkg -l play

<d02ka> ls play

GNUmakefile  SUBDIRS      VERSION      doc          src

<d02ka> ln -s ../play/play play //sets up a link for include area

<d02ka> cd ../play

<d02ka> mkdir play
    // This is a matter of some controversy: an area for the the header files;
    // I like a separate area

Now you are ready to play! In the following example, I make just a simple class, the sort of thing that you might write for a C++ class or tutorial.
Using the editor of your choice, open three files, header, source, and component test:

<d02ka> nedit play/atest.hpp src/atest.cpp src/atest_t.cpp

and see

/projects/702/l3_1/cope/example/example/play

for a trivial example. Note the processor directives to the include area.

<d02ka> nedit src/COMPONENTS
     //insert the name of the component (in this case atest)

<d02ka> cd ../ //should put you back in your release area

<d02ka>gmake play.test //will run the component test.

Hopefully the output will look like:

Testing component atest
Component atest tested ok

<d02ka> more tmp/IRIX6-KCC/play/ctest/atest.dir/ok.out

If something goes wrong: (the test failed or the executable faulted) the executable file will be in

tmp/IRIX6-KCC/play/ctest/atest.dir

For programming at this level, code examination and print statement debugging is probably your first recourse.

Likely problems:

• Not having setup D0RunII test
• Not issuing gmake from the "release directory"
• Not having the soft link correctly setup.
• Not having the correct link to the include area
• Not having the correct specification for the header file in src code
• Not having the header file in the correct place

<d02ka> nedit play/src/LIBRARIES // add needed libraries (m for math)

UPDATE :

Date: Wed, 31 Mar 1999 07:44:35 -0600
From: Amber Boehnlein <cope>
Subject: Re: confusion!!
To: Naresh Sen <nareshs@ruf.RICE.EDU>
Cc: d0-l3alg@fnal.gov, d0-l3soft@fnal.gov
Reply-to: cope@fnal.gov

Hi Naresh,

My guess is that the version that's "test" changed out from under you.
When you started to develop, t00.43.00 was test, and now t00.47.00 is test.
When I wrote the lessons, the word of mouth recommendation was to do
setup D0RunII test.
At the time, we went test with a release every week.
Now we seem to go test about once a month.
Last week, the release managers sent out a message
recommending that only specific versions be used.
The reasons given were very compelling,
and your experience shows what can go wrong.

I'm sorry for the confusion.
I recommended that everyone use test, and that looks like it was a bad idea.
Since this is general problem that could happen to others as well,
I'm sending this message out to the full group.

The version to use now is t00.47.00, and there are some changes with our stuff
relative to t00.43.00

So try:

setup D0RunII t00.47.00
newrel -t t00.47.00 t47
addpkg ctbuild
ctbuild.all
addpkg thispkg  //will get the package associated with the release
                // don't do -h! or you'll get the next version.
                // Gustaaf sent out a message about this last week.
and also copy in your code.

One big difference between t00.43.00 and t00.47.00 is that
t00.47.00 uses CTBUILD instead of CTEST

You'll need to make sure that the package level GNUmakefile have the line

include ctbuild/srt/srt.mk

instead of

include ctest/component.mk
                                                     Amber

On Mar 26,  2:09pm, Paul Russo wrote:
> Subject: Why "newrel -t test" is Evil
>
> The problem with doing a "newrel -t test" or a "setup D0Run test" is that
> when we switch the links your release area is suddenly tied to a
> different version of the release.  This *will* cause you all kinds of nasty
> and hard-to-understand trouble.  Your "*.d" files in the tmp area will
> have "test" hard coded into the filenames so they will suddenly start
> referring to totally different source code files without you having done
> anything at all---just one of the many bad things that will happen.
>
> Always, Always, Always use a specific release number instead!
>
> However, this is also not enough caution ... we have finite disk space and
> can keep a particular relase number around for only so many weeks, then it
> gets deleted.  You must continually be moving your test release area up to
> new release numbers.
>
> The best way to do this is to commit all your changes in your old release
> area, and delete it entirely.  Then, create a new test release area based
> on the most recent "golden" release and continue working from there.  On
> average your will have to do this about twice a month, the price of progress.
>
> Paul S. Russo
>-- End of excerpt from Paul Russo