Make alpha: Difference between revisions
No edit summary |
(Instructions for QA Team) |
||
(7 intermediate revisions by 2 users not shown) | |||
Line 23: | Line 23: | ||
# this build takes about 2 minutes | # this build takes about 2 minutes | ||
$ MAKE="make -j 4" nice -n +19 make -j 4 cgi-alpha > alpha.out 2>&1 | $ MAKE="make -j 4" nice -n +19 make -j 4 cgi-alpha > alpha.out 2>&1 | ||
# csh version: | |||
# (setenv MAKE "make -j 4"; nice +19 make -j 4 cgi-alpha) >& alpha.out | |||
# use the following grep to check for build errors | # use the following grep to check for build errors | ||
# it has no output with no errors present | |||
$ egrep -i "erro|warn" alpha.out | egrep -v "Werror|disabling jobserver mode" | $ egrep -i "erro|warn" alpha.out | egrep -v "Werror|disabling jobserver mode" | ||
$ cd hg/makeDb/trackDb # to be complete, do the trackDb and hgFindSpec tables also | $ cd hg/makeDb/trackDb # to be complete, do the trackDb and hgFindSpec tables also | ||
$ make alpha | $ make alpha # then email notify browser staff | ||
$ echo "Please note: /usr/local/apache/cgi-bin/ binaries have been updated for <reason>" \ | |||
| mail -s "new CGI's on genome-test" <browser staff email address> | |||
</PRE> | </PRE> | ||
This procedure is explicitly <B>not</B> encapsulated into a script because it is important for developers to understand what is happening here. You can make your own script if you want, but please understand what is happening here. | This procedure is explicitly <B>not</B> encapsulated into a script because it is important for developers to understand what is happening here. You can make your own script if you want, but please understand what is happening here. | ||
<HR> | |||
Note that members of the QA Team who never modify the code are exempt from some of these steps. In particular, QA members are not required to build from a new location; they can build directly from their sandbox (after a cvsup). It is still appropriate to send an email to browser-staff after building new binaries. | |||
[[Category:Browser Development]] | [[Category:Browser Development]] |
Latest revision as of 17:53, 8 November 2006
The 'make alpha' makefile target in the kent source tree is used to build the CGI binaries and related data files into the /usr/local/apache/cgi-bin/ hierarchy.
After a new browser feature is developed the 'make alpha' is used to deliver this feature to the genome-test browser to allow QA and other users of genome-test to begin testing the new feature.
To use the 'make alpha' procedure, keep in mind the following:
- use a local filesystem to the development machine to save compile time
- i.e. performing the build via an NFS filesystem is highly inefficient
- use a completely clean checkout of the source tree to use only top-of-tree source
- notify browser staff via email when install is done so everyone is aware that genome-test has changed
The recommended sequence is:
$ cd /scratch/$LOGNAME # work in local filesystem, mkdir here if you need one $ mv kent kent.old $ rm -fr kent.old & # remove any previous builds while new one takes place $ cvs co kent # checkout completely new source tree # this checkout can take several minutes depending upon # network traffic $ cd kent/src # the make command below uses 4 CPUs. nice it down # this build takes about 2 minutes $ MAKE="make -j 4" nice -n +19 make -j 4 cgi-alpha > alpha.out 2>&1 # csh version: # (setenv MAKE "make -j 4"; nice +19 make -j 4 cgi-alpha) >& alpha.out # use the following grep to check for build errors # it has no output with no errors present $ egrep -i "erro|warn" alpha.out | egrep -v "Werror|disabling jobserver mode" $ cd hg/makeDb/trackDb # to be complete, do the trackDb and hgFindSpec tables also $ make alpha # then email notify browser staff $ echo "Please note: /usr/local/apache/cgi-bin/ binaries have been updated for <reason>" \ | mail -s "new CGI's on genome-test" <browser staff email address>
This procedure is explicitly not encapsulated into a script because it is important for developers to understand what is happening here. You can make your own script if you want, but please understand what is happening here.
Note that members of the QA Team who never modify the code are exempt from some of these steps. In particular, QA members are not required to build from a new location; they can build directly from their sandbox (after a cvsup). It is still appropriate to send an email to browser-staff after building new binaries.