defaria.com/blogs/Status/archives/000358.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml" />
  11
  12    <title>Status for Andrew DeFaria: LOS178-570/int/package and check</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/000357.html" title="LOS178 TOT" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/000359.html" title="LOS178 TOT" />
  17
  18
  19
  20
  21
  22    <script type="text/javascript" src="http://defaria.com/blogs/Status/mt-site.js"></script>
  23 </head>
  24 <body class="layout-one-column" onload="individualArchivesOnLoad(commenter_name)">
  25    <div id="container">
  26       <div id="container-inner" class="pkg">
  27
  28          <div id="banner">
  29             <div id="banner-inner" class="pkg">
  30                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  31                <h2 id="banner-description">Searchable status reports and work log</h2>
  32             </div>
  33          </div>
  34
  35          <div id="pagebody">
  36             <div id="pagebody-inner" class="pkg">
  37                <div id="alpha">
  38                   <div id="alpha-inner" class="pkg">
  39
  40                      <p class="content-nav">
  41                         <a href="http://defaria.com/blogs/Status/archives/000357.html">&laquo; LOS178 TOT</a> |
  42                         <a href="http://defaria.com/blogs/Status/">Main</a>
  43                         | <a href="http://defaria.com/blogs/Status/archives/000359.html">LOS178 TOT &raquo;</a>
  44                      </p>
  45
  46                      <a id="a000358"></a>
  47                      <div class="entry" id="entry-358">
  48                         <h3 class="entry-header">LOS178-570/int/package and check</h3>
  49                         <div class="entry-content">
  50                            <div class="entry-body">
  51                               <ul>
  52   <li>Attempting to build LOS178 - CR 570 (Posix)</li>
  53
  54   <li>Tried to make changes for package.sh. Problems are:</li>
  55
  56   <ol>
  57     <li>Waiting for CR fom Moscow to address including of libstdc++ for LOS 2.1.0</li>
  58
  59     <li>GD lacks libstdc++ from ppc.cdksol.tar.gz! Entered CR #38 for that</lii>
  60
  61     <li>It was thought that changes to package.sh could be made without the need for a CR. Unfortunately the CVS setup is such that a CR is required, even for comitting changes to toolbox</li>
  62   </ol>
  63
  64   <li>Described new scripts for check and package. Check can be used to help tally the number of growing warnings</li>
  65
  66   <li>Described plan for a /int area so as to centralized our tools and scripts</li>
  67 </ul>
  68                            </div>
  69                            <div id="more" class="entry-more">
  70                               <h3>Check and Package</h3>
  71
  72 <p>I've done a little work on trying to come up with more generic scripts that can be used across build machines or indeed the organization. Specifically I've been targeting things like packaging and checking. My scripting language of choice is Perl.</p>
  73
  74 <p>All scripts are relative to my machine at present at saturn:/int. You are free to mount this file system from my machine to your machine to check out the code. In the future I plan on putting this all into a cvs repository and making if available to all who want/need it via a global file system such that adding /int/bin and perhaps /int/adm/bin to one's PATH is all that is needed to gain access to these scripts on any machine. Details of this will be forthcoming in another email.</p>
  75
  76 <p>In this message I will only describe the check and package scripts. Other scripts, including such things as cvs_report, ecrc as well as web pages and scripts will eventually be documented probably through a series of web pages.</p>
  77
  78 <h4>Check script</h4>
  79
  80 <p>Jas had asked me to enhance the checking of install.logs so as to keep track of the growing number of warnings. The check script does this. It will check for errors using the common error strings of other check like scripts as well as warning and optionally issue a total number of errors and warnings. The check script is in /int/bin/check. Here's a short usage:</p>
  81 <div class="code"><pre>
  82     Usage: check [-u] [-v] [-d] [-t] [-w] <logfile [logfile]>
  83
  84     Where:
  85
  86             -u              Display usage
  87             -v              Turn on verbose mode
  88             -d              Turn on debug mode
  89             -t              Display total line
  90             -w              Include warnings
  91             <logfile>       One or more log files to check
  92 </pre</div>
  93 <p>With no options except logfile(s) check will output nothing but set the return status to the number of errors encountered. This allows future script to be able to use this in their script and just check the return status.</p>
  94
  95 <h4>Package script</h4>
  96
  97 <p>The idea here is to separate the definition of a package from the packaging code itself. The hope is to hand the package definition over to the developers themselves so that they can maintain that - after all they know better what goes where than we do.</p>
  98
  99 <p>Packaging is implemented as a module, specifically a Perl module and as a Perl object itself. The idea is to encapsulate what can be done with a package into an object. The object module is at /int/lib/LWPackage.pm. The "LW" stands for "LynuxWorks". An LWPackage object currently has 3 methods: new, list and package. The new method is called to create a new package object. One parameter must be specified, that being a pathname to a package spec file. That package spec file is parsed and the package object is populated. The list method will list all of the information about the package including the file list. Finally the package method produces the package image itself.</p>
 100
 101 <p>Here is a small Perl snippet that utilizes the LWPackage methods:</p>
 102 <div class="code"><pre>
 103     my $pkg = LWPackage->new (spec => $spec);
 104     $pkg->list if get_verbose;
 105     $pkg->package;
 106 </pre></div>
 107 <p>In fact that's the main code for /int/bin/package, the packaging script. It creates a new LWPackage using the filename in $spec, calls the list method if verbose is turned on (get_verbose is part of the Display package) then calls the package method to create the package image.</p>
 108
 109 <h4>Package spec file</h4>
 110
 111 <p>Package spec files are denoted by the .lwp extension convention. The format of the spec file is pretty simple. As usual "#" indicate comments, etc. Look at /int/spec/* for example files. Basically the format is similar to:</p>
 112 <div class="code"><pre>
 113     Name:       int
 114     Version:    1.0
 115     ProductNbr: 1000
 116     Release:    00
 117     Base:       /int
 118     Fileset:
 119         *
 120         -data
 121     EndFileset
 122 </pre></div>
 123 <p>Name, ProductNbr, etc. are used in the creation of the image file name ($ProductNbr-$Release.$Name.$Version.tar.gz). The Fileset section defines the file sets included in the package relative to Base. An "*" denotes the usual connotation of "everything". Other path names could be listed one by one. For example, I could have:</p>
 124 <div class="code"><pre>
 125     Fileset:
 126         adm
 127         bin
 128         spec
 129         -data
 130         -web
 131     EndFileset
 132 </pre></div>
 133 <p>A minus sign does what you'd think - remove files denoted by this. So the above says, "everything under $Base except everything under $Base/data".</p>
 134
 135 <p>As for Fileset lines you can list multiple lines and they are processed in the order that they are entered. Duplicate filenames are removed and the Fileset list is ultimately sorted. You can list either directory names for whole directories (that are recursively processed) or individual file pathnames. Regex's are not supported (yet but should be).</p>
 136
 137 <p>The idea of a package spec is to define the Fileset from where they stand thus eliminating the need to copy large quantities of data into an alternate area so that that alternate area is "clean". IOW it should be able to pull only those necessary files from even a CVS or build tree directly. To that extend future arrangement of things into distinct areas will make writing packaging specs easier.</p>
 138
 139 <h3>A plan for /int</h4>
 140
 141 <p>We are seeking an NFS mountable global area where we can place various tools and scripts that will help us do our job. A previous email about the check and packaging scripts are an example of this. The basic idea is to be able to mount a global file system area to a short named path on the local system so that scripts like package and check, etc are accessible and readily available when needed.</p>
 142
 143 <p>So, for example, if t3:/export/int were that globally accessible file system one would mount t3:/export/int /int and then add /int/bin and perhaps /int/adm/bin to their path and these scripts would be available.</p>
 144
 145 <p>As these scripts will be used in business processes they are as valuable as our products themselves and thus should be placed under CVS. Let's assume that t3:/cvs/int-cvs were the CVS repository for these scripts. We could check out and modify our own scripts as we further develop them. A nightly cronjob could be set up to cvs export -r &gt;RELTAG&lt; /export/int to make sure that /export/int reflects <RELTAG> where &gt;RELTAG&lt; is some release tag. Then people could check out and enhance/modify our scripts in a test like environment and when "released" simply move the &gt;RELTAG&lt; to the committed version. The updated version would be available the next day (or we could force it by hand if necessary).</p>
 146
 147 <p>As for what gets put into /int I see the following directory structure:</p>
 148
 149 <blockquote>
 150 <b>adm:</b> Administrative area
 151   <blockquote>
 152   <b>bin:</b> Administrative bin scripts<br>
 153   <b>data:</b> Any adm data files that you might need<br>
 154   <b>etc:</b> Rough equivalent of /etc<br>
 155   <b>functions:</b> bash script functions (currently symlinked to ../functions)
 156   </blockquote>
 157 <b>bin:</b> Scripts and apps for int<br>
 158 <b>data:</b> Any data you might want<br>
 159 <b>functions:</b> bash script functions<br>
 160 <b>lib:</b> For Perl and other library modules<br>
 161 <b>spec:</b> Spec files (may get rid of this)<br>
 162 <b>test:</b> Any test scripts. For example, test script to test the functionality of the modules in ../lib<br>
 163 <b>web:</b> Might want to move this elsewhere. Basically a replica of the web pages and scripts I've been doing (so as to have a copy)
 164 </blockquote>
 165
 166 <p>Of course this can change and evolve over time. The main idea is to have a standard place that is globally accessible and short pathed (you could easily type /int/bin/check if /int/bin is not in your path) at a well known path name. Also to sort of replicate or mimic the OS's standard directories like bin, etc, and the like so that it's easily understandable and "natural".</p>
 167                            </div>
 168                         </div>
 169                         <p class="entry-footer">
 170                            <span class="post-footers">Posted by  on May 18, 2005  6:27 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000358.html">Permalink</a>
 171                         </p>
 172                      </div>
 173
 174
 175
 176
 177                   </div>
 178                </div>
 179             </div>
 180          </div>
 181       </div>
 182    </div>
 183 </body>
 184 </html>