Downlink Building Guide ======================= Modification History: --------------------- vsn 1.0 F. Masci 10/29/04 Initial version for S12.0 and beyond. ---------------------------------------------------------------------------- Location of this file: $SOS_VERSION/downlink/builds/README 1. Solaris Nightly (and Weekly) Builds: --------------------------------------- First set-up a crontab file on your machine: type "crontab -e", which gets you into a vi editor. Add the lines: 0 0 * * 0-6 /ssc/pipe/S12.0D/sw/nightly/nightly_build.csh 0 10 * * 0 /ssc/pipe/S12.0D/sw/nightly/downlink/builds/weekly_build.csh This means that the nightly build script will be executed at midnight every night from day 0 (Sunday) to day 6 (following Saturday), and the weekly build script every Sunday at 10am. *** Ensure that the file .../downlink/builds/nightly_build.csh exists under /ssc/pipe/S12.0D/sw/nightly/ (SOS_VERSION in downlink_generic.env) Following the build, two e-mails are sent, one is a cron-job log and another contains a tally of the number of binaries, libraries and scripts. The build log is contained in the file .../downlink/build_log. You can check for errors by scanning the build_log for the word "Fatal". 2. Linux Nightly Builds: ------------------------ On sscpipe20, set up the crontab file just as above. Add the following line: 0 0 * * 0-6 /scr/nightly/S12.0D/nightly_build_linux.csh *** Ensure that the file .../downlink/builds/nightly_build_linux.csh exists under /scr/nightly/S12.0D/ (SOS_VERSION in downlink_generic_linux.env) N.B. Linux builds do not send automated e-mail messages. You can check for errors by scanning the .../downlink/build_log for the word "Fatal". 3. On changing the SOS_REL in the DEV (nightly) environment: ------------------------------------------------------------ i. Update all SOS_REL pointers in crontab file above. ii. Update SOS_REL in all .../downlink/build/* scripts, except the downlink_segtest.env file which is for segment test. iii. Update /ssc/pipe/S*.*D to indicate new SOS_REL. iv. Update all SOS_REL pointers in file .../downlink/builds/SOS_REL_UpdateEmail.txt and e-mail this to ssc-downlink and ISTs. 4. Tagging Downlink at Code Freeze time (e.g., for S12.0): ---------------------------------------------------------- i. cd to an area (e.g., your /scr) which has >~ 300MB; mkdir S12.0_freeze; cd S12.0_freeze; ii. CVS check-out downlink and concurrent sdm and common repositories: cvs checkout -P downlink cvs checkout -P sdm cvs checkout -P common iii. Do a recursive tag on all files and save the output: cvs tag -F -R BugFixTagS12 downlink | tee LOG_S12downlinkTag cvs tag -F -R BugFixTagS12 sdm | tee LOG_S12sdmTag cvs tag -F -R BugFixTagS12 common | tee LOG_S12commonTag (Note: sdm and common are tagged for verification/bookeeping only) iv. Send the following e-mail to ssc-downlink (re-wordind the date according to when you did the tag): ...................................................................... Effective Monday Aug. 9, please use the following CVS check-in procedure: i. If you are developing code for **future** deliveries, add and commit your code the normal way as you have been doing (no tags, no fuss). ii. For bug-fixes/updates you want included in the S12.0 delivery, (a). cvs commit -m "" (b). cvs tag -F BugFixTagS12 ***Don't forget to perform (b) following each and every commit*** ...................................................................... 5. Building on the Segment Test System (segdnl): ------------------------------------------------ i. Ensure SOS_REL in .../downlink/builds/downlink_segtest.env is up to date. ii. To perform a fresh baseline build, see instructions in the header of .../downlink/builds/segment_build.csh 6. Delivering to I&T after the Segment Test Period: --------------------------------------------------- i. Find all files which are not tagged in downlink repository. Check with developers that these are indeed intended for the future and not part of the current delivery. e.g., for the S12.0 delivery, untagged files are found as follows: cvs checkout -r BugFixTagS12 -P downlink | tee TagLOG; rm -rf downlink cvs checkout -P downlink | tee NoTagLOG diff TagLOG NoTagLOG > NotTagged.txt The file NotTagged.txt will indicate which files have no tags. ii. Perform a test build of tagged system at end of segment test: In .../downlink/builds/segment_build.csh, replace the line "cvs checkout -P downlink" with one which checks out all s/w with the specific tag, e.g., for S12.0, replace this with: cvs checkout -r BugFixTagS12 -P downlink Now proceed as normal with the test build on segdnl by following the instructions in .../downlink/builds/segment_build.csh iii. Assuming successful completion of the test build, update the SOS_REL pointer in downlink_IandT.env and downlink_IandT_linux.env iv. Update documentation .../downlink/builds/downlink_building_IandT.doc Ensure the SOS_REL and "tag" identifier is correct in step 3. Ensure the binary and library numbers are correct in step 8. Make pdf copies of these documents and check into D/L repository. v. Check the following files into the "cm" repository under .../cm/tools/build/ build_downlink_IandT.csh downlink_IandT.env downlink_IandT_linux.env twoPassBuild.csh downlink_building_IandT.pdf vi. Email Rich, indicating that downlink is ready to build and attach the downlink_building_IandT.pdf file to the e-mail. 7. Patching downlink after Delivery to I&T: ------------------------------------------- Please update all SOS_REL pointers in the file .../downlink/builds/IandTPatchInstructions.txt and e-mail it to ssc-downlink. 8. What environment file do I source if I simply want to manually build a module or library? ----------------------------------------------------------------- To manually build a module or library (i.e., by cd'ing into appropriate level directory and executing make), you must first source /ssc/pipe/S?.?D/sw/nightly/downlink/builds/ \ downlink_generic.env if on a regular DEV machine, or, /ssctst1/sos1/sw/$SOS_REL/downlink/builds/downlink_segtest.env if on the segment test system, or, /scr/nightly/$SOS_REL/ \ downlink/builds/downlink_generic_linux.env if on our Linux machine "sscpipe20". 9. How do I manually build a module or library with the DEBUG flag and with no optimization flags so that it can be analyzed with a debugger? ------------------------------------------------------- For Solaris: Add the following line below "include $(SIRTFROOT)/env/def.mk" in the "leaf" makefile for C-code: CFLAGS_opt = $(CFLAGS_COM) -g or, the leaf makefile for Fortran-code: FFLAGS_opt = $(FFLAGS_COM) -g For Linux: Simply append a "-g" to either the "DFLAG = $(DFLAG_CC)" line for C code, or, the "DFLAG = $(DFLAG_FC)" line for Fortran in the "leaf" makefiles, e.g: DFLAG = $(DFLAG_CC) -g or DFLAG = $(DFLAG_FC) -g 10. To remove "Sticky Tags" if you initially checked out a repository under a specific tag and CVS prevents you from re-committing files to the main trunk: ---------------------------------------------------------- Simplest fix is to remove the tags in all CVS/ subdirectories. e.g., to remove all BugFixTagS12 tags from a checkout under this tag on segdnl: find * | xargs /ssctst1/sos1/sw/S12.0/downlink/perltools/ \ replaceword 'TBugFixTagS12' '' 11. What if something goes wrong in the nightly builds and we need to point to the weekly build version in the DEV environment? ------------------------------------------------------------- If we are in S12.0 for example, e-mail the following to ssc-downlink: setenv SIRTF_LIB /ssc/pipe/S12.0D/sw/weekly/downlink setenv SIRTFROOT /downlink setenv ARCH FORTE setenv SIRTF_ARCH ${SIRTFROOT} setenv SIRTF_TARG DEV setenv LD_LIBRARY_PATH ${SIRTF_LIB}/lib:${LD_LIBRARY_PATH} where is your path containing your checked out version of the downlink repository. 12. Updating the "Master (top-level) Makefiles": ------------------------------------------------ There are 14 of these distributed in the downlink repository. It is the buildmeister's responsibility to update these at the developer's request. To avoid developer's modifying these in CVS, it is advised that the buildmeister keeps a backup of all of them in their private area.