Changes between Version 7 and Version 8 of Obsolete/Development/Build
- Timestamp:
- Jun 30, 2010, 2:09:43 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Obsolete/Development/Build
v7 v8 1 = Quattor Build Tools = 1 2 [[TracNav]] 3 4 [[TOC(inline)]] 2 5 3 6 The quattor build tools aim to wrap up all the functions commonly used by developers to manage code in the quattor repository. They provide facilities for creating new releases of software modules, and include automatic checks for required elements. This page is a technical guide for developers who want to contribute code to quattor. … … 9 12 Each core module has its own pointer to the build tools, which appears as a normal subdirectory named `quattor-build-tools` in the checkout directory. For NCM components there is instead a single pointer located at `quattor/ncm-components/`. '''In any case, please, refrain from making any change to the content of any `quattor-build-tools` directory!''' 10 13 11 = System requirements=14 == System requirements == 12 15 The framework is based on GNU '''make''', '''sed''', '''grep''', '''perl''', etc. Please make sure you're using some version of GNU/Linux. MacOS, BSD and others are '''not''' supported. Then of course, you need a recent version (at least `>= 1.4.4`) of `svn`. 13 16 14 = Workspace setup = 17 == Workspace setup == 18 15 19 First, make sure your finger information is up-to-date. This is needed to fill the 'author' field in the change logs. If needed run the following command: 16 20 {{{ 17 21 $ chfn -f <full-name> -o <email-address> <your-login> 18 22 }}} 23 19 24 We recommend to check out repository directories with their original names, f.i.: 20 25 {{{ 21 $ svn co https://quattor.svn.sourceforge.net/svnroot/quattor/ foo/bar quattor/foo/bar26 $ svn co https://quattor.svn.sourceforge.net/svnroot/quattor/trunk/foo/bar quattor/foo/bar 22 27 }}} 28 23 29 The above command makes '''$PWD/quattor''' your working directory (a.k.a. the quattor checkout root). 24 30 If however you prefer to use a different checkout root as a working directory, you should set the following environment variable: … … 28 34 Better off placing it in your `~/.bashrc`. Make sure you have write permission on `/your/quattor/working/dir`! The above variable will help the build tools to guess where to create the tags in your local system. 29 35 30 == Core modules == 36 '''Note: working copy of Quattor repository must always comme from Quattor trunk.''' 37 38 === Core modules === 31 39 In order to work with core modules, just check out the directory you're interested in, f.i.: 32 40 {{{ … … 39 47 }}} 40 48 41 == NCM components==49 === NCM components === 42 50 In order to work with NCM components, you need to check out the '''whole''' components' tree, i.e., for the head revisions: 43 51 {{{ … … 56 64 }}} 57 65 58 = Available targets=66 == Build Tools Available Targets == 59 67 From now we assume each ''target'' is called via `make`. For example, to invoke the help command inside a given product directory, f.i. `ncm-components/core/ncm-grub/`: 60 68 {{{ … … 89 97 90 98 91 = Versioning=99 == Versioning == 92 100 Module versions are made up of a 3-digit ''version'' number and a 1-digit ''release'' number: 93 101 {{{ … … 101 109 The VERSION string `x.y.z` is ''automatically'' modified by the build tools, whereas the RELEAE string `n` must be modified ''manually'' in special situations, such as when back porting fixes to an old version. 102 110 103 = Checking in releases=111 == Checking in releases == 104 112 After the initial check-in to add a module to the repository, subsequent releases are handled via the following '''make''' targets: 105 113 … … 130 138 This will cause a `stable` tag to be created with the contents of the current revision. 131 139 132 = Checking code=140 == Checking code == 133 141 In order to improve the quality of our code base, the build framework runs some automatic checks when 134 142 performing checkins. You can run these checks manually using the `check` target. Further details of the checks performed may be found [wiki:BuildFrameworkChecks here]. 135 143 136 = Deprecating a module=144 == Deprecating a module == 137 145 When a module or NCM component is deprecated for any reason, it should be marked as 'obsolete'. 138 146 The convention for obsolete modules is to have an `OBSOLETE` tag in `config.mk` with three possible values: … … 149 157 Once a module is marked as obsolete, unless you define the shell variable `CHKOBS_OK`, '''make check''' fails. Other targets depending on `check`, such as `rpm`, will also fail. 150 158 151 = Running unit tests=159 == Running unit tests == 152 160 If your module comes with unit tests, you can call them via '''make test''', provided that a test ''harness'' is found in your checkout. Further details may be found on [https://twiki.cern.ch/twiki/bin/view/FIOgroup/SWDevUnitTestPerl CERN's Perl unit test page]. 153 161 154 = Updating a core module's pointer to the build tools=162 == Updating a core module's pointer to the build tools == 155 163 Normally, each core module has a pointer to a specific version of the build tools, set as an `svn:externals` property. You can query it by running '''svn pg svn:externals''', f.i. for the `aii` core module: 156 164 {{{ … … 179 187 '''__Note__: NCM components use always the head revision of the build tools''', thus the above procedure does not apply to them. 180 188 181 == Updating all pointers to the build tools==189 === Updating all pointers to the build tools === 182 190 From the top-level trunk directory it is possible to update all the pointers to the latest build tools in just one go: 183 191 {{{
