Status for Andrew DeFaria

• Exposed salira2 vob
• Set up multisite schedule for sons-sc-cc to mimic sons-clearcase. Before this sync receives were only performed once! Things started backing up in the storage bays. All cleared out now.
• Attempted to build 4.0. Had problems in dynamic view
• Managed to build in 4.0 snapshot view.
• Figured out that certain exe's were missing execute permission in Clearcase Element Properties. Seems Clearcase 2003.06.00 is a bit more picky about those than Clearcase 2002.05.00! Build now works in dynamic view as well

TIme Spent: 2 hours

Simon Zhu wrote:

Similar to sc_3.1_dev, I made config spec sc_4.0_dev. It does not make any difference since I could not find “cenopon” under salira2 when I load the view. It seems to me that the VOB was not fully replicated. You may take a look. Thanks.

The szhu_view4.0 has a config spec of:

#element * CHECKEDOUT
#element * /main/LATEST
include //sons-sc-cc/views/official/salira/neopon/cs/sc_4.0_dev
#load \salira\neopon
load \salira2

And the following lines appeared in sc_4.0_dev:

# Now pickup any new elements created at the other site
element * .../rel_3.1/LATEST -mkbranch sc_4.0
element * .../china_4.0/LATEST -mkbranch sc_4.0

This should be:

# Now pickup any new elements created at the other site
element * .../rel_4.0/LATEST -mkbranch sc_4.0

element * .../china_4.0/LATEST -mkbranch sc_4.0

We can see this in the version tree for the root folder \salira2 :

Prior to fixing the config spec the "eye" pointed to /main/0, which, of course is empty.

Next I attempted simply a make. Most of it worked! Except:

[LINKING]      vxWorks_st.elf 
Converting to bin...
/bin/bash: maketools/convert: Permission denied
make: *** [scs.bin] Error 126
[ccadmin] sons-sc-cc:ls maketools

I don't know why I get permission denied when attempting to run maketools/convert. This is only happening in a dynamic view. I created a 4.0_snap view and the build worked fine.

Ah ah! It appears that the execute bit on the Properties of the Element for maketools/convert.exe was not set, even on sons-clearcase. However it also appears that Clearcase 2002.05.00 didn't care about that but the new Clearcase 2003.06.00 does. I toggled the execute bits on for convert.exe (and other .exe's in maketools) and all is fine.

Since your view is a snapshot view you'll need to simply do a ct setcs -current.

Posted by at 10:39 PM | Permalink

• Got XAM ant build to work. Test build almost working
• Ported Build.pl for use in XAM

I assume you mean the state of XAM. Here's what I've done:

• Moved .../platform/L3/platform/src/com/hp/platform/fcas -> .../platform/XAM/server/src/com/hp/platform/fcas
• Moved .../platform/L3/platform/src/test/com/hp/platform/fcas -> .../platform/XAM/server/src/test/com/hp/platform/fcas
• Moved .../riss/W2/xam/client -> .../platform/XAM/client/c

By "moved" I mean that I copied those areas from the old place to the new place, added them to source control and rmnamed the old areas. This is as per Rational's recommendation for moving things in a UCM environment.

Next I attempted to build fcas in the new area. It became quickly apparent that we need to port over the buildTools directory with its build_common.xml if we wish to replicate the build environment of L3.

With Rahul's help I managed to build the server component in XAM. I have not tackled the client component nor test at this time. I've checked in the buildTools/build_common.xml and the build.xml under the server area.

Here's how you can build XAM:

• If necessary rebase your RISS15_xam substream or create view from RISS15_xam
• Change directory to .../platform/XAM/server/src/com/hp/platform/fcas
• type "ant -Dbase_dir=/vobs/platform/XAM -DviewBase=/vobs"

Note: viewBase would be different if you are using a snapshot view.

Since XAM will be separated from L3 the question is: How are dependencies handled? For example, this XAM "depends on" or "imports" code from L3's core and csfr. To address this we added:

<pathelement path="${viewBase}/platform/L3/code"/>

to the ext.classpath in build_common.xml even though the comment for this states:

<!--
    Class path element for Build. Don't add libraries here Libraries
    should go under devenv/buildenv/lib those libs will be
    automatically picked up by the following element
-->

You see we now have two different types of libraries, ext.classpath libraries that are built elsewhere and just deposited into devenv/buildenv/lib and our own libraries that are built in another component (in this case the L3 component).

Also, the above ${viewBase}/platform/L3/code assumes that that directory exists and contains compiled class files. It assume that L3 was built before XAM is built. This introduces the notion of dependencies between components.

Finally you'll note that we don't build from the /vobs/platform/XAM level, rather we descend down into the /vobs/platform/XAM/server/src/com/hp/platform/fcas level to do our ant build. Questions:

• Do we need a Build.pl to sit in /vobs/platform/XAM to build everything underneath it?
• Can't ant do recursive ants like make does recursive makes?

Posted by at 7:15 PM | Permalink