Building on sons-sc-cc (Fixing smake)

  • Posted on
  • by
  • in
  • Looked into build issues on sons-sc-cc
  • Adjusted smake

Time Spent: 2 hours

This problem with drive letters being unavailable when one remotely logs in is one that I had battled with for a while in the past as history shows.

Unfortunately I don't have a great solution yet except to say that most people do not log into the server directly to do a build as you are doing. However there's a light at the end of the tunnel and that light is smake. Smake makes an optimization by setting TOOLS_DIR to the local disk drive instead of the T drive when building on sons-clearcase (and sons-cc for that matter as well as a sonsbld1 that we were once trying to set up). As a result I've changed smake to add sons-sc-cc to the list:

if [ $myhost = "sons-sc-cc" ]; then
  export TOOLS_ROOT=D:/Tools && nice make -e "$@"
elif [ $myhost = "sons-clearcase" ]; then
  export TOOLS_ROOT=E:/Tools && nice make -e "$@"
elif [ $myhost = "sons-cc" -o $myhost = "sonsbld1" ]; then
  export TOOLS_ROOT=C:/Tools && nice make -e "$@"
else
  nice make "$@"
fi

So if you use smake instead of just make on sons-sc-cc TOOLS_ROOT will be set to D:/Tools (where Tools are locally on sons-sc-cc) and then it will call make. This should solve this problem for local makes. For remove smakes (an smake you invoke from your desktop - you guys still do that right?) the following code changes fix that:

if [ $build_server = "sons-sc-cc" ]; then
  rsh -n $build_server "ct $(pwd) && export TOOLS_ROOT=D:/Tools
&& nice make -e $@"
elif [ $build_server = "sons-cc" -o $build_server = "sonsbld1" ]; then
  rsh -n $build_server "cd $(pwd) && export TOOLS_ROOT=C:/Tools
&& nice make -e $@"
else
  rsh -n $build_server "cd $(pwd) && export TOOLS_ROOT=E:/Tools
&& nice make -e $@"
fi

The added benefit of this approach is that builds a a lot faster since you are not loading the compiler over the network connection of the T drive (even though the T drive points back to the local machine in the case of sons-sc-cc).

Oh, another optimization I did on sons-sc-cc - I change the share cache to cache programs that are run. So for users running builds locally on there desktops (well not yet but when we get fully switched over) and they load say the C compiler from vxWorks, it will be cached on their local desktop and subsequent compilations should also run a lot faster!

I'm still not able to build, however. Here's a build from a clean view. Note that I removed the * from your /etc/passwd line szhu so I could use rsh to switch users from ccadmin -> szhu:

[ccadmin] sons-sc-cc:rsh -l szhu sons-sc-cc
No directory /us/SZhu!
Logging in with home = "/".
Last login: Tue Apr 18 11:06:10 from sc-szhu.salira.com
CYGWIN_NT-5.2 SONS-SC-CC 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin
WARNING: HOME directory did not exist! Logging in with HOME = /tmp

SZhu@SONS-SC-CC ~
$ id
uid=1143(SZhu) gid=513(Domain Users) groups=513(Domain Users)
  
SZhu@SONS-SC-CC ~
$ cd /dview/3.1.ccadmin/salira/neopon/build/
SZhu@SONS-SC-CC
/dview/3.1.ccadmin/salira/neopon/build
$ which smake
/view/official/Tools/bin/smake
SZhu@SONS-SC-CC
/dview/3.1.ccadmin/salira/neopon/build
$ smake
Build server: sons-sc-cc View: 3.1.ccadmin [local]
User: SZhu Dir: /dview/3.1.ccadmin/salira/neopon/build
Performing build locally on sons-sc-cc
sons-sc-cc:make 

                   +---------------------------+
                  /       S a l i r a         /|
                 /          NEOPON           / |
                /---------------------------/  |
                |             |O|           |  /
                | Building... |L|           | /
                |             |C|           |/
                +---------------------------+
-------------------------------------- (neopon/src/bsp) olc
[ASSEMBLE]     sysALib.s
[COMPILE C]    sysLib.c
[COMPILE C]    sysTffs.c
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c: In function `tffsShowAll':
In file included from sysTffs.c:63:
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c:205: warning: comparison between signed and unsigned
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c: In function `tffsBootImagePut':
D:/TOols/Tornado-2.0/target/src/drv/tffs/tffsConfig.c:389: warning: comparison between signed and unsigned
[COMPILE C]    8260I2C.c
8260I2C.c: In function `i2cInit':
8260I2C.c:260: warning: cast from pointer to integer of different size
8260I2C.c:261: warning: cast from pointer to integer of different size
8260I2C.c:265: warning: cast from pointer to integer of different size
8260I2C.c:266: warning: cast from pointer to integer of different size
[COMPILE C]    Fpga_download.c
[COMPILE C]    usrConfig_st.c
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c: In function `usrTffsLnConfig':
In file included from usrExtra.c:203,
                 from usrConfig_st.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c:154: warning: implicit declaration of function `dosFsMkfsOptionsSet'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c: In function `vxTaskCreate':
In file included from usrExtra.c:236,
                 from usrConfig_st.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c:581: warning: unused parameter `stackBase'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c: In function `wvOn':
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c:269: warning: unused parameter `arg4'
[COMPILE C]    usrConfig.c
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c: In function `usrTffsLnConfig':
In file included from usrExtra.c:203,
                 from usrConfig.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrTffs.c:154: warning: implicit declaration of function `dosFsMkfsOptionsSet'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c: In function `vxTaskCreate':
In file included from usrExtra.c:236,
                 from usrConfig.c:123:
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWdb.c:581: warning: unused parameter `stackBase'
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c: In function `wvOn':
D:/TOols/Tornado-2.0/target/src/config/../../src/config/usrWindview.c:269: warning: unused parameter `arg4'
[COMPILE C]    fpd_end.c
fpd_end.c: In function `np3400EndAddressForm':
fpd_end.c:1247: too few arguments to function `endEtherAddressForm'
make[2]: *** [../../../build/olc/obj/fpd_end.o] Error 1
make[1]: *** [obj/bsp/olc.olist] Error 2
make: *** [olc/vxWorks_st.elf] Error 2
Regarding checkin and bug ID labeling, when you check into Clearcase using sons-clearcase you are saying that the trigger that is supposed to label the check in with the bug ID is failing to do so. I will look into this later too.

I'm not seeing this. In fact I'm seeing evidence saying it's working. The triggers log to /view/official/Tools/logs/triggers.log. Looking at the bottom of that file (tail -f works nicely) shows me:

CheckinPreop.pl: 4/18/2006@17:38: vdsouza: Checkin checks started for V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch
CheckinPreop.pl: 4/18/2006@17:38: vdsouza: Successful precheckin of V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch with bug ID
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Created label for BUGS200006029
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Attached label BUGS200006029 to V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c
CheckinPostop.pl: 4/18/2006@17:38: vdsouza: Successful postcheckin of V:\vdsouza3.1\salira\neopon\src\gdb\gdb_csr_dump.c on rel_3.1 branch with bug ID BUGS200006029

And indeed gdb_csr_dump.c has a label of BUGS200006029:

[ccadmin] sons-clearcase:files4bug 6029
Files involved in bug ID BUGS200006029:
        /salira/neopon/src/gdb/main/rel_2.0/hainan_integration/rel_2.2/rel_3/1/gdb_csr_dump.c

1 file involved in bug ID BUGS200006029

Do you have an example of where this is failing?