[BACK]Return to readme.html CVS log [TXT] [DIR] Up to [LON-CAPA] / loncom / build

Diff for /loncom/build/readme.html between versions 1.13 and 1.18

version 1.13, 2001/01/17 13:40:29 version 1.18, 2002/04/27 16:31:39
Line 1 Line 1
 <HTML>  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 <HEAD>   "http://www.w3.org/TR/html4/loose.dtd">
 <META NAME="GENERATOR" CONTENT="Scott Harrison and Emacs Version 3.14159265358979">  <!-- The LearningOnline Network with CAPA -->
 <TITLE>LON-CAPA Software Developer Instructions</TITLE>  <!-- $Id$ -->
 </HEAD>  <html>
 <BODY>  <head>
 <H1>LON-CAPA Software Developer Instructions</H1>  <meta name="GENERATOR"
 <BR><I>Written by Scott Harrison, January 17, 2001</I>        content="Scott Harrison and Emacs Version 3.14159265358979" />
 <BR><I>Last updated, January 17, 2001</I>  <title>LON-CAPA Software Developer Instructions</title>
 <OL>  </head>
 <LI><A HREF="#Using_CVS">Using CVS</A>  <body>
 <UL>  <h1>LON-CAPA Software Developer Instructions</h1>
 <LI><A HREF="#cvslog">Logging in and out (cvs login; cvs logout)</A>  <p>
 <LI><A HREF="#cvsget">Getting files (cvs update -d)</A>  <br /><i>Written by Scott Harrison, January 17, 2001</i>
 <LI><A HREF="#cvsupdate">Updating files (cvs update -d)</A>  <br /><i>Last updated, April 27, 2002</i>
 <LI><A HREF="#cvssave">Saving files (cvs commit)</A>  </p>
 <LI><A HREF="#cvsadd">Adding files (cvs add)</A>  <ol>
 <LI><A HREF="#cvsadddir">Adding directories (cvs add/import)</A>  <li><a href="#Using_CVS">Using CVS</a></li>
 <LI><A HREF="#cvsnotsure">What to do when you're not sure about your files (cvs update)</A>  <ul>
 </UL>  <li><a href="#cvslog">Logging in and out (cvs login; cvs logout)</a></li>
 <LI><A HREF="#makeHTML">Viewing the software (make HTML)</A>  <li><a href="#cvsupdate">Updating files (cvs update -d)</a></li>
 <LI><A HREF="#makebuild">Compiling the software (make build)</A>  <li><a href="#cvssave">Saving files (cvs commit)</a></li>
 <LI><A HREF="#loncapafiles">Adding/removing files from the LON-CAPA installation (doc/loncapafiles/loncapafiles.html)</A>  <li><a href="#cvsadd">Adding files (cvs add)</a></li>
 <LI><A HREF="#configversusnonconfig">Configurable files versus non-configurable files</A>  <li><a href="#cvsadddir">Adding directories (cvs add/import)</a></li>
 <LI><A HREF="#makeinstall">Updating the non-configurable files on your machine (make install)</A>  <li><a href="#cvsnotsure">What to do when you're not sure about your files
 <LI><A HREF="#makeconfiginstall">Updating the configurable files on your machine (make configinstall)</A>  (cvs update)</a></li>
 <LI><A HREF="#makeRPM">Building RPMs (make RPM)</A>  </ul>
 </OL>  <li><a href="#makeHTML">Viewing the software (make HTML)</a></li>
   <li><a href="#makebuild">Compiling the software (make build)</a></li>
 <OL>  <li><a href="#loncapafiles">Adding/removing files from the LON-CAPA
 <A NAME="Using_CVS">  installation (doc/loncapafiles/loncapafiles.lpml)</a></li>
 <LI><H2>Using CVS</H2>  <li><a href="#configversusnonconfig">Configurable files versus
 <UL>  non-configurable files</a></li>
 <LI><A NAME="cvslog">  <li><a href="#makeinstall">Updating the non-configurable files on your
     <H3>Using CVS: Logging in and out (cvs login; cvs logout)</H3>  machine (make install)</a></li>
 <LI><A NAME="cvsget">  <li><a href="#makeconfiginstall">Updating the configurable files on your
     <H3>Using CVS: Getting files (cvs update -d)</H3>  machine (make configinstall)</a></li>
 <LI><A NAME="cvsupdate">  <li><a href="#makeRPM">Building RPMs (make RPM)</a></li>
     <H3>Using CVS: Updating files (cvs update -d)</H3>  </ol>
 <LI><A NAME="cvssave">  
     <H3>Using CVS: Saving files (cvs commit)</H3>  <ol>
 <LI><A NAME="cvsadd">  <a name="Using_CVS" />
     <H3>Using CVS: Adding files (cvs add)</H3>  <li><h2>Using CVS</h2></li>
 <LI><A NAME="cvsadddir">  These instructions assume that you are using a Linux or UNIX based
     <H3>Using CVS: Adding directories (cvs add/import)</H3>  terminal.
 <LI><A NAME="cvsnotsure">  <ul>
     <H3>Using CVS: What to do when you're not sure about your files (cvs update)</H3>  <li><a name="cvslog" />
 </UL>      <h3>Using CVS: Logging in and out (cvs login; cvs logout)</h3>
 <LI><A NAME="makeHTML">  <p>
     <H2>Viewing the software (make HTML)</H2>  To log into CVS, CVS needs to be part of your system environment.
 <STRONG>Commands</STRONG>  You can accomplish this by:
 <FONT COLOR="#008800">  <font color="#008800">
 <PRE>  <pre>
   export CVSROOT=:pserver:USERNAME@install.lon-capa.org:/home/cvs
   </pre>
   </font>
   </p>
   <p>
   To actually login, you will need to execute the following command:
   <font color="#008800">
   <pre>
   cvs login
   </pre>
   </font>
   You will be prompted for a password.
   If you do not have a password, or the password is not working, you
   should contact <a href="mailto:helen@lon-capa.org">helen@lon-capa.org</a>
   </p>
   <p>
   If you have yet to check out the CVS repository, you can use the
   <tt>checkout</tt> command.  (Otherwise, just enter your
   CVS repository, <tt>cd loncapa</tt>.)
   <font color="#008800">
   <pre>
   cvs checkout loncapa
   cd loncapa
   </pre>
   </font>
   </p>
   <p>After you have completed your work with the CVS repository, it
   is recommended that you log out:
   <font color="#008800">
   <pre>
   cvs logout
   </pre>
   </font>
   </p>
   </li>
   <li><a name="cvsupdate" />
       <h3>Using CVS: Updating files (cvs update -d)</h3>
   <p>
   After entering your CVS source tree (<tt>cd loncapa</tt>),
   you should frequently update the software changes that
   programmers other than yourself have made.  This is done
   with the <tt>update</tt> command.
   <font color="#008800">
   <pre>
   cvs update -d
   </pre>
   </font>
   </p>
   <p>
   The <tt>cvs update</tt> command will give you output
   as it updates your CVS source tree.  Commonly you will
   see 'U' and 'P' which indicate that a file has been updated with
   changes another programmer has made.
   <font color="#880000">
   <pre>
   `U FILE'
        The file was brought up to date with respect to the repository.
        This is done for any file that exists in the repository but not in
        your source, and for files that you haven't changed but are not
        the most recent versions available in the repository.
   
   `P FILE'
        Like `U', but the CVS server sends a patch instead of an entire
        file.  These two things accomplish the same thing.
   </pre>
   </font>
   </p>
   <p>
   Usually, when you do not <tt>cvs commit</tt> the code changes that you
   make, the <tt>update</tt> command will tell you that you have modified
   your file with the 'M' flag.
   <font color="#880000">
   <pre>
   `M FILE'
        The file is modified in  your  working  directory.  This is probably
        based on changes you made and have not yet "cvs commit"-ed.
   </pre>
   </font>
   Sometimes, it will occur that:
   <ul>
   <li>you have modified a file and not yet committed it</li>
   <li>someone else *has* modified a file and *has* committed it</li>
   </ul>
   Generally speaking, this is <strong>your</strong> fault.  It is your
   responsibility to resolve conflicts.  <tt>cvs update</tt> informs
   you of a conflict with the 'C' flag.
   <font color="#880000">
   <pre>
   `C FILE'
        A conflict was detected while trying to merge your changes to FILE
        with changes from the source repository.
   </pre>
   </font>
   You will need to open the file and examine it; CVS will have added in
   markup tags like "&lt;&lt;&lt;&lt;&lt;&lt;" to tell you about the merging
   conflicts.  (Sometimes, CVS will intelligently merge in other changes and
   give you the 'M' flag, but many times you will have to manually edit
   the file as just described.)
   </p>
   </li>
   <li><a name="cvssave" />
       <h3>Using CVS: Saving files (cvs commit)</h3>
   <p>
   <tt>cvs commit</tt> works to submit changes to an <strong>existing</strong>
   file within the repository.  If a file does not currently exist, then you
   will first need to <tt>cvs add</tt> it as described in the following
   section.
   </p>
   Running the <tt>cvs commit</tt> command without passing it an argument will
   commit all changes that you have within the current directory and
   subdirectories.
   <font color="#008800">
   <pre>
   cvs commit
   </pre>
   </font>
   </p>
   <p>
   A more precise approach to using <tt>cvs commit</tt> is to pass it specific
   file names.  (Usually you should do this.)
   <font color="#008800">
   <pre>
   cvs commit FILENAME
   </pre>
   </font>
   </p>
   <p>
   Note that CVS typically invokes the <tt>vi</tt> editor and solicits comments
   about your latest changes to the software.   Your comments should be
   both short yet uniquely descriptive.  For example:
   <ul>
   <li><strong>BAD</strong> - "made some changes and am drinking soda"</li>
   <li><strong>GOOD</strong> - "implemented syntax checking of perl scripts
   with -c flag"</li>
   </ul>
   </p>
   </li>
   <li><a name="cvsadd" />
       <h3>Using CVS: Adding files (cvs add)</h3>
   <p>
   <font color="#008800">
   <pre>
   cvs add FILENAME
   </pre>
   </font>
   </p>
   <p>
   Then you can run <tt>cvs commit FILENAME</tt> and this file will
   become an "official" part of LON-CAPA.
   </p>
   </li>
   <li><a name="cvsadddir" />
       <h3>Using CVS: Adding directories (cvs add/import)</h3>
   <p>
   <font color="#008800">
   <pre>
   cvs add DIRECTORYNAME
   </pre>
   </font>
   </p>
   <p>
   There is no need to run <tt>cvs commit</tt>.  Directories immediately
   become part of the LON-CAPA CVS source tree by only using the <tt>cvs add</tt>
   command.
   </p>
   </li>
   <li><a name="cvsnotsure" />
       <h3>Using CVS: What to do when you're not sure about your files
           (cvs update -d)</h3>
   <p>
   Every once in a while, multiple programmers may be working on the
   same file.  Most conflicts are avoidable if everybody regularly
   <strong>commits</strong> their changes AND if everybody
   regularly <strong>updates</strong> the CVS source tree they are working on.
   </p>
   <p>
   In other words, if you are absent from programming for a few days, and
   <strong>fail</strong> to run <tt>cvs update -d</tt> on your CVS source
   repository, you have only yourself to blame if you find yourself writing
   code in a file that is not up-to-date.
   </p>
   </li>
   </ul>
   <li><a name="makeHTML" />
       <h2>Viewing the software (make HTML)</h2></li>
   <strong>Commands</strong>
   <font color="#008800">
   <pre>
 cd loncom/build  cd loncom/build
 rm -Rf HTML <I>(or alternatively, "make clean")</I>  rm -Rf HTML <I>(or alternatively, "make clean")</I>
 make HTML  make HTML
 cd HTML  cd HTML
 <I>(look at the index.html file with a web browser such as Netscape)</I>  <I>(look at the index.html file with a web browser such as Netscape)</I>
 </PRE>  </pre>
 </FONT>  </font>
 <STRONG>General description of what happens</STRONG>  <strong>General description of what happens</strong>
 <P>  <p>
 This is the actual make target code.  This is the actual make target code.
 <FONT COLOR="#880000">  <font color="#880000">
 <PRE>  <pre>
 <!-- LONCAPA MAKETARGET=HTML START -->  <!-- LONCAPA MAKETARGET=HTML START -->
 HTML:  HTML:
         install -d HTML   install -d HTML
         cp ../../doc/loncapafiles/*.gif HTML   cp $(SOURCE)/doc/loncapafiles/*.gif HTML
         perl parse.pl ../../doc/loncapafiles/loncapafiles.html HTML > HTML/index.html   cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
    perl lpml_parse.pl html development default "$(SOURCE)" '$(TARGET)' \
    > HTML/index.html
 <!-- LONCAPA MAKETARGET=HTML END -->  <!-- LONCAPA MAKETARGET=HTML END -->
 </PRE>  </pre>
 </FONT>  </font>
 What basically happens is that specially marked-up data in the LON-CAPA  What basically happens is that specially marked-up data in the LON-CAPA
 cvs repository file <TT>doc/loncapafiles.html</TT> is parsed into a more  cvs repository file <tt>doc/loncapafiles.lpml</tt> is parsed into a more
 viewable format by <TT>loncom/build/parse.pl</TT>.  The resulting  viewable format by <tt>loncom/build/lpml_parse.pl</tt>.  The resulting
 file gives a very well organized view of all the files, directories,  file gives a very well organized view of all the files, directories,
 links, ownerships, permissions, and brief documentation of what each  links, ownerships, permissions, and brief documentation of what each
 file does.  file does.
 </P>  </p>
 <LI><A NAME="makebuild">  <li><a name="makebuild" />
     <H2>Compiling the software (make build)</H2>      <h2>Compiling the software (make build)</h2>
 <STRONG>Commands</STRONG>  <strong>Commands</strong>
 <FONT COLOR="#008800">  <font color="#008800">
 <PRE>  <pre>
 cd loncom/build  cd loncom/build
 make build  make build
 </PRE>  </pre>
 </FONT>  </font>
 <STRONG>General description of what happens</STRONG>  <p>
 <P>  <strong>General description of what happens</strong>
   </p>
   <p>
 This is the actual make target code.  This is the actual make target code.
 <FONT COLOR="#880000">  <font color="#880000">
 <PRE>  <pre>
 <!-- LONCAPA MAKETARGET=build START -->  <!-- LONCAPA MAKETARGET=build START -->
 build:  build: Makefile.build pod2html.sh pod2man.sh
         perl parse.pl ../../doc/loncapafiles/loncapafiles.html build > Makefile.build   echo -n "" > WARNINGS
         make -f Makefile.build all   make -f Makefile.build all
    make warningnote
   
   Makefile.build: $(SOURCE)/doc/loncapafiles/loncapafiles.lpml lpml_parse.pl
    cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
    perl lpml_parse.pl build $(CATEGORY) $(DIST) "$(SOURCE)" "$(TARGET)" \
    > Makefile.build
 <!-- LONCAPA MAKETARGET=build END -->  <!-- LONCAPA MAKETARGET=build END -->
 </PRE>  </pre>
 </FONT>  </font>
 <TT>loncom/build/parse.pl</TT> reads in all the build information out  <tt>loncom/build/lpml_parse.pl</tt> reads in all the build information out
 of <TT>doc/loncapafiles/loncapafiles.html</TT>.  A new Makefile named  of <tt>doc/loncapafiles/loncapafiles.lpml</tt>.  A new Makefile named
 <TT>loncom/build/Makefile.build</TT> is dynamically constructed.  <tt>loncom/build/Makefile.build</tt> is dynamically constructed.
 This dynamically generated Makefile is then run to build/compile  This dynamically generated Makefile is then run to build/compile
 all the software targets from source.  This currently takes 10 minutes  all the software targets from source.  This currently takes 10 minutes
 (depends on the speed of the machine you compile with).  (depends on the speed of the machine you compile with).
 </P>  </p>
 <STRONG>Example</STRONG>  <strong>Example</strong>
 <P>  <p>
 Here is information for one file <TT>tth.so</TT> provided in  Here is information for one file <tt>tth.so</tt> provided in
 <TT>doc/loncapafiles/loncapafiles.html</TT>.  <tt>doc/loncapafiles/loncapafiles.lpml</tt>.
 <FONT COLOR="#330066">  <font color="#330066">
 <PRE>  <pre>
 <BR>&lt;METAGROUP&gt;  &lt;file&gt;
 <BR>&lt;LONCAPA TYPE=LOCATION DIST="redhat6.2" SOURCE="loncom/modules/TexConvert/tthperl/tth.so" TARGET="usr/lib/perl5/site_perl/5.005/tth.so" CATEGORY="system file"&gt;  &lt;source&gt;loncom/homework/caparesponse/capa.so&lt;/source&gt;
 <BR>&lt;DESCRIPTION&gt;  &lt;target dist='default'&gt;usr/lib/perl5/site_perl/5.005/capa.so&lt;/target&gt;
 <BR>shared library file for dynamic loading and unloading of TeX-to-HTML functionality  &lt;target dist='redhat7 redhat7.1'&gt;usr/lib/perl5/site_perl/5.6.0/capa.so&lt;/target&gt;
 <BR>&lt;/DESCRIPTION&gt;  &lt;categoryname&gt;system file&lt;/categoryname&gt;
 <BR>&lt;BUILD&gt;  &lt;description&gt;
 <BR>loncom/modules/TexConvert/tthperl/commands  shared library file for dynamic loading and unloading
 <BR>&lt;/BUILD&gt;  &lt;/description&gt;
 <BR>&lt;DEPENDENCIES&gt;  &lt;build trigger='always run'&gt;
 <BR>../tthdynamic/tthfunc.c  loncom/homework/caparesponse/commands
 <BR>../ttmdynamic/ttmfunc.c  &lt;/build&gt;
 <BR>&lt;/DEPENDENCIES&gt;  &lt;dependencies&gt;
 </PRE>  caparesponse.c;
 </FONT>  caparesponse.pm;
 <TT>loncom/build/parse.pl</TT> sees the <B>BUILD</B> tags and sets up  README;
 a dynamic file <TT>Makefile.build</TT> to run the command inside the  Makefile.PL;
 <B>BUILD</B> tags (currently, <B>DEPENDENCIES</B> is not used for anything  capa.i;
 besides documentation).  commands
 </P>  &lt;/dependencies&gt;
 <P>  &lt;/file&gt;
 Here is an example of a dynamically generated <TT>Makefile.build</TT>  </pre>
 that builds two LON-CAPA files (one of which is <TT>tth.so</TT>).  </font>
 <FONT COLOR="#330066">  <tt>loncom/build/lpml_parse.pl</tt> sees the <b>build</b> tags and sets up
 <PRE>  a dynamic file <tt>Makefile.build</tt> to run the command inside the
   <b>build</b> tags.  The files listed inside the <b>dependencies</b> tags
   are included in the <tt>Makefile.build</tt> so as to determine whether
   or not there is a need to compile.
   </p>
   <p>
   Here is an example of a dynamically generated <tt>Makefile.build</tt>
   that builds two LON-CAPA files (one of which is <tt>tth.so</tt>).
   <font color="#330066">
   <pre>
 all: ../homework/caparesponse/capa.so ../modules/TexConvert/tthperl/tth.so   all: ../homework/caparesponse/capa.so ../modules/TexConvert/tthperl/tth.so 
   
 ../homework/caparesponse/capa.so:  ../homework/caparesponse/caparesponse.c ../ho  ../homework/caparesponse/capa.so:  ../homework/caparesponse/caparesponse.c ../homework/caparesponse/caparesponse.pm alwaysrun
 mework/caparesponse/caparesponse.pm alwaysrun  
         cd ../homework/caparesponse/; sh ./commands          cd ../homework/caparesponse/; sh ./commands
   
 ../modules/TexConvert/tthperl/tth.so:  ../modules/TexConvert/tthperl/../tthdynam  ../modules/TexConvert/tthperl/tth.so:  ../modules/TexConvert/tthperl/../tthdynamic/tthfunc.c ../modules/TexConvert/tthperl/../ttmdynamic/ttmfunc.c
 ic/tthfunc.c ../modules/TexConvert/tthperl/../ttmdynamic/ttmfunc.c  
         cd ../modules/TexConvert/tthperl/; sh ./commands          cd ../modules/TexConvert/tthperl/; sh ./commands
   
 alwaysrun:  alwaysrun:
 </PRE>  </pre>
 </FONT>  </font>
 </P>  </p>
 <LI><A NAME="loncapafiles">  </li><li><a name="loncapafiles" />
     <H2>Adding/removing files from the LON-CAPA installation (doc/loncapafiles/loncapafiles.html)</H2>      <h2>Adding/removing files from the LON-CAPA installation (doc/loncapafiles/loncapafiles.html)</h2>
 <STRONG>To add and remove (and alter)</STRONG>  <strong>To add and remove (and alter)</strong>
 <P>  <p>
 All that you have to do to alter the behavior of the installation is  All that you have to do to alter the behavior of the installation is
 edit a single file (<TT>doc/loncapafiles/loncapafiles.html</TT>).  edit a single file (<tt>doc/loncapafiles/loncapafiles.lpml</tt>).
 Adding, removing, and altering files requires proper attention  Adding, removing, and altering files requires proper attention
 to the syntax of file format of course.  to the syntax of file format of course.
 </P>  </p>
 <STRONG>File Format</STRONG>  <strong>File Format</strong>
 <P>  <P>
 The preceding <A HREF=#"makebuild">"make build"</A> documentation  The preceding <a href=#"makebuild">"make build"</a> documentation
 gives an example <B>METAGROUP</B> entry describing one particular file.  gives an example of a <b>file</b> entry describing one particular file.
 All data within <TT>loncapafiles.html</TT> is specified according  All data within <tt>loncapafiles.lpml</tt> is specified according
 to markup tags.  The format and syntax of <TT>loncapafiles.html</TT>  to markup tags.  The format and syntax of <tt>loncapafiles.lpml</tt>
 is currently best described by the HTML documentation code at the beginning of  is currently best described by the HTML documentation code at the beginning of
 loncapafiles.html (as well as, by example, seeing how various  loncapafiles.html (as well as, by example, seeing how various
 information is coded).  All in all, the syntax is quite simple.  information is coded).  All in all, the syntax is quite simple.
 </P>  </p>
 <STRONG>Philosophy and notes (the thing nobody reads)</STRONG>  <strong>Philosophy and notes (the thing nobody reads)</strong>
 <P>  <p>
 Packaging the software from CVS onto a machine file system requires many  Packaging the software from CVS onto a machine file system requires many
 things:  things:
 <UL>  <ul>
 <LI>documenting every component of the software,  <li>documenting every component of the software,</li>
 <LI>handling CVS <U>source</U> to file system <U>target</U> information  <li>handling CVS <u>source</u> to file system <u>target</u> information,</li>
 <LI>handling (according to a hierarchical scheme of grouping) file  <li>handling (according to a hierarchical scheme of grouping) file
 ownership and permissions,  ownership and permissions,</li>
 <LI>handling (according to a hierarchical scheme of grouping) directory  <li>handling (according to a hierarchical scheme of grouping) directory
 ownership and permissions,  ownership and permissions,</li>
 <LI>handling symbolic links  <li>handling symbolic links,</li>
 <LI>providing for multiple options of installation targets  <li>providing for multiple options of installation targets
 (RedHat versus Debian for instance),  (RedHat versus Debian for instance),</li>
 <LI>providing for different file ownerships and permissions to apply  <li>providing for different file ownerships and permissions to apply
 to the same file,  to the same file,</li>
 <LI>allowing system software documentation to be automatically generated  <li>allowing system software documentation to be automatically generated
 (see information on <A HREF="#makeHTML">"make html"</A>),  (see information on <a href="#makeHTML">"make html"</a>),</li>
 <LI>providing information in an easily adjustable form as new demands  <li>providing information in an easily adjustable form as new demands
 are made on the software packaging system,  are made on the software packaging system,</li>
 <LI>providing software package information (for RPM),  <li>providing software package information (for RPM),</li>
 <LI>having information in a format that allows for troubleshooting  <li>having information in a format that allows for troubleshooting
 the current status of the machine file system,  the current status of the machine file system,</li>
 <LI>allow for changes to the structure of the CVS repository,  <li>allow for changes to the structure of the CVS repository,</li>
 <LI>and something that is simple enough for any one to immediately work with,  <li>and something that is simple enough for any one to immediately work with,
 without having to learn specifics (or hidden traps) of complicated Makefile's  without having to learn specifics (or hidden traps) of complicated Makefile's
 or a new macro language (m4?).  or a new macro language (m4?).</li>
 </UL>  </ul>
 </P>  </p>
 <P>  <p>
 I looked into, and tried, different ways of accomplishing the above  I looked into, and tried, different ways of accomplishing the above
 including automake and recursive make.  The automake system seemed quite  including automake and recursive make.  The automake system seemed quite
 complicated (and needlessly so in terms of this project since, by and large,  complicated (and needlessly so in terms of this project since, by and large,
Line 209  is kept in one place, and there are sign Line 414  is kept in one place, and there are sign
 between all the things that must be done to keep software packaging  between all the things that must be done to keep software packaging
 up to date.  A particularly convincing article I found when looking into  up to date.  A particularly convincing article I found when looking into
 much of this was  much of this was
 <A HREF="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html">  <a href="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html">
 "Recursive Make Considered Harmful" by Peter Miller</A>.  Complicating  "Recursive Make Considered Harmful" by Peter Miller</a>.  Complicating
 matters was, at the time, it was unclear as to what categories  matters was, at the time, it was unclear as to what categories
 of software files we had, and whether or not the directory structure  of software files we had, and whether or not the directory structure
 of CVS would remain constant.  With an ever-developing directory structure  of CVS would remain constant.  With an ever-developing directory structure
 to CVS, I preferred to organize the information on a per-file basis  to CVS, I preferred to organize the information on a per-file basis
 as opposed to a per-directory basis (although there is a successful  as opposed to a per-directory basis (although there is a successful
 implementation of a standard big Makefile in <TT>loncom/Makefile</TT>).  implementation of a standard big Makefile in <tt>loncom/Makefile</tt>).
 Additionally, a standard big Makefile assumes certain "normalcy" to  Additionally, a standard big Makefile assumes certain "normalcy" to
 the directory structure of different potential operating system directories  the directory structure of different potential operating system directories
 (RedHat vs. Debian).  (RedHat vs. Debian).
 </P>  </p>
 <P>  <p>
 If you take time to look at loncapafiles.html  If you take time to look at loncapafiles.lpml
 (and perhaps run the <A HREF="#makeHTML">make HTML</A> command)  (and perhaps run the <a href="#makeHTML">make HTML</a> command)
 you will find that the organizing information according to the markup  you will find that the organizing information according to the markup
 syntax in <TT>loncapafiles.html</TT> is simple.  Simple is good.  syntax in <tt>loncapafiles.lpml</tt> is simple.  Simple is good.
 </P>  </p>
 <P>  <p>
 <TT>loncom/build/parse.pl</TT> is the script (invoked automatically  <tt>loncom/build/lpml_parse.pl</tt> is the script (invoked automatically
 by the various targets in <TT>loncom/build/Makefile</TT>) that reads  by the various targets in <tt>loncom/build/Makefile</tt>) that reads
 <TT>doc/loncapafiles/loncapafiles.html</TT>.  <TT>parse.pl</TT>  <tt>doc/loncapafiles/loncapafiles.lpml</tt>.  <tt>lpml_parse.pl</tt>
 is capable of reading and returning different types of information  is capable of reading and returning different types of information
 from <TT>loncapafiles.html</TT> depending on how <TT>parse.pl</TT>  from <tt>loncapafiles.lpml</tt> depending on how <tt>lpml_parse.pl</tt>
 is invoked.  <TT>parse.pl</TT> has yet to have introduced new sources  is invoked.  <tt>lpml_parse.pl</tt> has yet to have introduced new sources
 of error, and has been tested in quite a number of ways.  As with  of error, and has been tested in quite a number of ways.  As with
 any parser however, I remain paranoid.  any parser however, I remain paranoid.
 </P>  </p>
 <P>  <p>
 My regrets with the current system is that <TT>parse.pl</TT> is  <tt>lpml_parse.pl</tt> is very fast and styled after a state-based SAX-like
 slow (can take 1 minute to run) and includes a few tidbits of code,  approach.  Additionally, <tt>loncapafiles.lpml</tt> has a 
 specific to the make process, that probably should be in  DTD (loncom/build/lpml.dtd) against which it is valid.
 <TT>loncom/build/Makefile</TT>.  Additionally, <TT>loncapafiles.html</TT>  I would like to use more ENTITY's inside <tt>lpml.dtd</tt> but currently
 should have a DTD and all those other good SGML-ish things (and parsing  Perl XML modules available at CPAN do not digest complex ENTITY's that well.
 should be done with a real SGML-derived parser).  </p>
 </P>  <p>
 <P>  The <tt>lpml_parse.pl</tt>-<tt>loncapafiles.lpml</tt> 
 On the plus side, the <TT>parse.pl</TT>-<TT>loncapafiles.html</TT>   
 combination has been working very efficiently and error-free.  combination has been working very efficiently and error-free.
 </P>  </p>
 <LI><A NAME="configversusnonconfig">  </li><li><a name="configversusnonconfig" />
     <H2>Configurable files versus non-configurable files</H2>      <h2>Configurable files versus non-configurable files</h2>
 <STRONG>Machine-specific information is the difference</STRONG>  <p>
 <P>  <strong>Machine-specific information is the difference</strong>
   </p>
   <p>
 The current list of configurable files for the LON-CAPA system is  The current list of configurable files for the LON-CAPA system is
 /etc/httpd/access.conf, /etc/smb.conf, /etc/ntp.conf, /etc/krb.conf,  /etc/httpd/access.conf, /etc/smb.conf, /etc/ntp.conf, /etc/krb.conf,
 /etc/atalk/config, /etc/ntp/step-tickers,   /etc/atalk/config, /etc/ntp/step-tickers, 
Line 260  The current list of configurable files f Line 466  The current list of configurable files f
 /home/httpd/html/res/adm/includes/un_keyword.tab,   /home/httpd/html/res/adm/includes/un_keyword.tab, 
 /home/httpd/hosts.tab, and  /home/httpd/hosts.tab, and
 /home/httpd/spare.tab.  /home/httpd/spare.tab.
 </P>  </p>
 <P>  <p>
 All of these configurable files contain machine-specific information.  All of these configurable files contain machine-specific information.
 For instance, the LON-CAPA system relies on unique host IDs such  For instance, the LON-CAPA system relies on unique host IDs such
 as msua3, s1, s2, msul1, and 103a1 (specified as a "PerlSetVar lonHostID"  as msua3, s1, s2, msul1, and 103a1 (specified as a "PerlSetVar lonHostID"
 field within /etc/httpd/access.conf).  field within /etc/httpd/access.conf).
 Non-configurable files simply do NOT have machine-specific information.  Non-configurable files simply do NOT have machine-specific information.
 <STRONG>The impact on updating software</STRONG>  <strong>The impact on updating software</strong>
 <P>  <p>
 What this means in terms of software updating is that  What this means in terms of software updating is that
 <UL>  <ul>
 <LI>non-configurable files can be simply overwritten with newer versions  <li>non-configurable files can be simply overwritten with newer versions
 (without "anything" else to worry about),  (without "anything" else to worry about),</li>
 <LI>and configurable files must follow these steps to be safely overwritten  <li>and configurable files must follow these steps to be safely
 <OL>  overwritten</li>
 <LI>have their machine specific information saved,  <ol>
 <LI>be overwritten, and then  <li>have their machine specific information saved,</li>
 <LI>have their machine specific information restored.  <li>be overwritten, and then</li>
 </UL>  <li>have their machine specific information restored.</li>
 </P>  </ol>
 <LI><A NAME="makeinstall">  </ul>
     <H2>Updating the non-configurable files on your machine (make install)</H2>  </p>
 <STRONG>Commands</STRONG>  <li><a name="makeinstall" />
 <FONT COLOR="#008800">      <h2>Updating the non-configurable files on your machine (make install)</h2>
 <PRE>  <strong>Commands</strong>
   <font color="#008800">
   <pre>
 cd loncom/build  cd loncom/build
 make install  make install
 </PRE>  </pre>
 </FONT>  </font>
 <STRONG>General description of what happens</STRONG>  <p>
 <P>  <strong>General description of what happens</strong>
   </p>
   <p>
 This is the actual make target code.  This is the actual make target code.
 <FONT COLOR="#880000">  <font color="#880000">
 <PRE>  <pre>
 <!-- LONCAPA MAKETARGET=install START -->  <!-- LONCAPA MAKETARGET=install START -->
 install: build  install: TEST_hosts_tab Makefile.install Makefile
         perl parse.pl ../../doc/loncapafiles/loncapafiles.html install > Makefil   echo -n "" > WARNINGS
 e.install   make -f Makefile.install SOURCE="$(SOURCE)" TARGET="$(TARGET)" \
         make -f Makefile.install SOURCE="../.." TARGET="" directories   directories
         make -f Makefile.install SOURCE="../.." TARGET="" files   make -f Makefile.install SOURCE="$(SOURCE)" TARGET="$(TARGET)" files
         make -f Makefile.install SOURCE="../.." TARGET="" links   make -f Makefile.install SOURCE="$(SOURCE)" TARGET="$(TARGET)" links
    make SOURCE="$(SOURCE)" TARGET="$(TARGET)" \
    NORESTORECONF="$(NORESTORECONF)" configinstall
    make postinstall
    make warningnote
    echo "You can run 'make test' to see if your system is ready to go!"
   
   Makefile.install: $(SOURCE)/doc/loncapafiles/loncapafiles.lpml lpml_parse.pl
    cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
    perl lpml_parse.pl install $(CATEGORY) $(DIST) "$(SOURCE)" \
    "$(TARGET)" > Makefile.install
 <!-- LONCAPA MAKETARGET=install END -->  <!-- LONCAPA MAKETARGET=install END -->
 </PRE>  </pre>
 </FONT>  </font>
 For safety reasons (so as to not mess up a machine's configuration),  For safety reasons (so as to not mess up a machine's configuration),
 configuration files are NOT installed during this step.  This means  configuration files are NOT installed during this step.  This means
 that files such as /etc/httpd/access.conf, /etc/smb.conf, /etc/atalk/config,  that files such as /etc/httpd/access.conf, /etc/smb.conf, /etc/atalk/config,
Line 311  that files such as /etc/httpd/access.con Line 531  that files such as /etc/httpd/access.con
 /home/httpd/spare.tab are not overwritten, but remain as old, non-updated  /home/httpd/spare.tab are not overwritten, but remain as old, non-updated
 copies.  (To automatically update these files and save/restore  copies.  (To automatically update these files and save/restore
 their encoded machine configuration, you must run "make configinstall").  their encoded machine configuration, you must run "make configinstall").
 </P>  </p>
 <LI><A NAME="makeconfiginstall">  <li><a name="makeconfiginstall" />
     <H2>Updating the configurable files on your machine (make configinstall)</H2>    <h2>Updating the configurable files on your machine (make configinstall)</h2>
 <STRONG>Commands</STRONG>  <strong>Commands</strong>
 <FONT COLOR="#008800">  <font color="#008800">
 <PRE>  <pre>
 cd loncom/build  cd loncom/build
 make configinstall  make configinstall
 </PRE>  </pre>
 </FONT>  </font>
 <STRONG>General description of what happens</STRONG>  <strong>General description of what happens</strong>
 <P>  <p>
 This is the actual make target code.  This is the actual make target code.
 <FONT COLOR="#880000">  <font color="#880000">
 <PRE>  <pre>
 <!-- LONCAPA MAKETARGET=configinstall START -->  <!-- LONCAPA MAKETARGET=configinstall START -->
 configinstall:   configinstall: Makefile.configinstall
         # there is a dependency on having directories in place, but oh well...   make -f Makefile.configinstall SOURCE="$(SOURCE)" TARGET="$(TARGET)" \
         perl parse.pl ../../doc/loncapafiles/loncapafiles.html configinstall > Makefile.configinstall   configfiles
         make -f Makefile.configinstall SOURCE="../.." TARGET="" configfiles   if (test "0" = $(NORESTORECONF)); then \
         perl loncaparestoreconfigurations lasttimestamp   perl loncaparestoreconfigurations suffix .lpmlnew; fi
         make -f Makefile.configinstall TARGET="" configpermissions  
   Makefile.configinstall: $(SOURCE)/doc/loncapafiles/loncapafiles.lpml lpml_parse.pl
    cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
    perl lpml_parse.pl configinstall $(CATEGORY) $(DIST) "$(SOURCE)" \
    "$(TARGET)" > Makefile.configinstall
 <!-- LONCAPA MAKETARGET=configinstall END -->  <!-- LONCAPA MAKETARGET=configinstall END -->
 </PRE>  </pre>
 </FONT>  </font>
 Configuration files are installed during this step.  This means  Configuration files are installed during this step.  This means
 that files such as /etc/httpd/access.conf, /etc/smb.conf, /etc/atalk/config,  that files such as /etc/httpd/access.conf, /etc/smb.conf, /etc/atalk/config,
 /home/httpd/html/res/adm/includes/copyright.tab, and  /home/httpd/html/res/adm/includes/copyright.tab, and
 /home/httpd/spare.tab are overwritten.  Before being overwritten,  /home/httpd/spare.tab are overwritten.  Before being overwritten,
 a backup copy is made though.  Information is read out of these  a backup copy is made though.  Information is read out of these
 backup copies and restored to the new files by the  backup copies and restored to the new files by the
 <TT>loncaparestoreconfigurations</TT> script.  To ensure that  <tt>loncaparestoreconfigurations</tt> script.  To ensure that
 new file permissions and ownerships are installed, a final set of  new file permissions and ownerships are installed, a final set of
 <TT>chown</TT> and <TT>chmod</TT> commands are called upon all  <tt>chown</tt> and <tt>chmod</tt> commands are called for each of 
 the configuration files.  the configuration files.
 </P>  </p>
 <STRONG>For the truly paranoid</STRONG>  <p>
 <P>  <strong>For the truly paranoid</strong>
   </p>
   <p>
 If you are truly paranoid, you can just make the  If you are truly paranoid, you can just make the
 <TT>Makefile.configinstall</TT> file and then save, copy,  <tt>Makefile.configinstall</tt> file and then save, copy,
 and restore all the configuration values yourself.  and restore all the configuration values yourself.
 <TT>loncaparestoreconfigurations</TT> is pretty smart though, has yet to  <tt>loncaparestoreconfigurations</tt> is pretty smart though, has yet to
 fail, and besides, a backup copy is always made (time-stamped so that backup  fail, and besides, when needed backup copies are made.
 copies are not overwritten).  </p>
 </P>  </li><li><a name="makeRPM" />
 <LI><A NAME="makeRPM">      <h2>Building RPMs (make RPM)</h2>
     <H2>Building RPMs (make RPM)</H2>  <p>
 <STRONG>Commands</STRONG>  LON-CAPA is currently installed through "intelligent tarballs".  This
 <FONT COLOR="#008800">  is part of an earlier (and perhaps future) effort involving RPMs.
 <PRE>  <strong>Commands</strong>
   <font color="#008800">
   <pre>
 cd loncom/build  cd loncom/build
 rm -Rf BinaryRootL <I>(or alternatively, "make clean")</I>  rm -Rf BinaryRoot <I>(or alternatively, "make clean")</I>
 make RPM  make RPM
 <I>(to subsequently install, you can type commands like     <I>(to subsequently install, you can type commands like
 "rpm -Uvh --force LON-CAPA-base-3.1-1.i386.rpm")         "rpm -Uvh --force LON-CAPA-base-3.1-1.i386.rpm")</I>
 </PRE>  </pre>
 </FONT>  </font>
 </P>  </p>
 <STRONG>WARNING!!!!!!!!!!!!!!</STRONG>  <strong>WARNING!!!!!!!!!!!!!!</strong>
 <P>  <p>
 Never never never never never manually install the  Never never never never never manually install the
 LON-CAPA-setup-3.1-1.i386.rpm.  This RPM is meant to only be  LON-CAPA-setup-3.1-1.i386.rpm.  This RPM is meant to only be
 installed by the CD installation process (it wipes out  installed by the CD installation process (it wipes out
 the existing /etc/passwd file).  the existing /etc/passwd file).
 </P>  </p>
 <STRONG>Configuration files</STRONG>  <p>
 <P>  <strong>Configuration files</strong>
   </p>
   <p>
 Configuration files are automatically saved with the file suffix  Configuration files are automatically saved with the file suffix
 ".rpmsave".  So <TT>/etc/httpd/conf/access.conf</TT> is saved as   ".rpmsave".  So <tt>/etc/httpd/conf/access.conf</tt> is saved as 
 <TT>/etc/httpd/conf/access.conf.rpmsave</TT>.  You can restore  <tt>/etc/httpd/conf/access.conf.rpmsave</tt>.  You can restore
 the machine-specific configuration information by running  the machine-specific configuration information by running
 the <TT>/usr/sbin/loncaparestoreconfigurations</TT>.  However,  the <tt>/usr/sbin/loncaparestoreconfigurations</tt>.  However,
 a <B>warning</B> is important here.  If you install an RPM twice  a <b>warning</b> is important here.  If you install an RPM twice
 without restoring your configuration, you will overwrite the  without restoring your configuration, you will overwrite the
 ".rpmsave" files.  ".rpmsave" files.
 </P>  </p>
 <STRONG>General description of what happens</STRONG>  <p>
 <P>  <strong>General description of what happens</strong>
   </p>
   <p>
 This is the actual make target code.  This is the actual make target code.
 <FONT COLOR="#880000">  <font color="#880000">
 <PRE>  <pre>
 <!-- LONCAPA MAKETARGET=RPM START -->  <!-- LONCAPA MAKETARGET=RPM START -->
 RPM: BinaryRoot  RPM: BinaryRoot base_rpm_file_list
         cat base_file_list.txt | perl make_rpm.pl base 3.1 '' '' BinaryRoot   cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
         cat setup_file_list.txt | perl make_rpm.pl setup 3.1 '' '' BinaryRoot   perl lpml_parse.pl make_rpm $(CATEGORY) $(DIST) $(SOURCE) $(TARGET) \
    > base_customizerpm.xml
    cat base_rpm_file_list.txt | perl make_rpm.pl base 3.2 '' '' \
    BinaryRoot base_customizerpm.xml
   
   BinaryRoot: base_rpm_file_list
    make TARGET='BinaryRoot' NORESTORECONF='1' install
   
 BinaryRoot:  base_rpm_file_list:
         perl parse.pl ../../doc/loncapafiles/loncapafiles.html BinaryRoot   cat $(SOURCE)/doc/loncapafiles/loncapafiles.lpml | \
    perl lpml_parse.pl rpm_file_list $(CATEGORY) $(DIST) $(SOURCE) \
    'BinaryRoot' | sort > base_rpm_file_list.txt
 <!-- LONCAPA MAKETARGET=RPM END -->  <!-- LONCAPA MAKETARGET=RPM END -->
 </PRE>  </pre>
 </FONT>  </font>
 A <TT>BinaryRoot</TT> directory is generated that reflects the locations,  A <tt>BinaryRoot</tt> directory is generated that reflects the locations,
 ownerships, permissions, and contents for all the CVS source  ownerships, permissions, and contents for all the CVS source
 files, compiled binaries, directories, and links as they should eventually  files, compiled binaries, directories, and links as they should eventually
 occur on the '/' filesystem location.  occur on the '/' filesystem location.
 </P>  </p>
 <P>  <p>
 <TT>loncom/build/make_rpm.pl</TT> is robust (tested over the  <tt>loncom/build/make_rpm.pl</tt> is robust (tested over the
 span of months) and, unlike other automated RPM-builders, cleanly  span of months) and, unlike other automated RPM-builders, cleanly
 builds new RPMs without any after-effect of temporary files left  builds new RPMs without any after-effect of temporary files left
 on the system.  (On the negative side, there are a number of  on the system.  (On the negative side, there are a number of
Line 416  LON-CAPA specific customizations inside Line 656  LON-CAPA specific customizations inside
 the sake of reusability, should eventually be removed).  Two new RPMs  the sake of reusability, should eventually be removed).  Two new RPMs
 are generated: LON-CAPA-base-3.1-1.i386 and LON-CAPA-setup-3.1-1.i386.rpm  are generated: LON-CAPA-base-3.1-1.i386 and LON-CAPA-setup-3.1-1.i386.rpm
 (again, never manually install LON-CAPA-setup-3.1-1.i386.rpm).  (again, never manually install LON-CAPA-setup-3.1-1.i386.rpm).
 </P>  </p>
 </OL>  </li>
 </BODY>  </ol>
 </HTML>  </body>
   </html>
   
   
   
Removed from v.1.13  
changed lines
  Added in v.1.18

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>