Annotation of loncom/build/readme.html, revision 1.12
1.11 harris41 1: <HTML>
2: <HEAD>
3: <META NAME="GENERATOR" CONTENT="Scott Harrison and Emacs Version 3.14159265358979">
4: <TITLE>LON-CAPA Software Developer Instructions</TITLE>
5: </HEAD>
6: <BODY>
1.1 harris41 7: <H1>LON-CAPA Software Developer Instructions</H1>
1.12 ! harris41 8: <BR><I>Written by Scott Harrison, January 17, 2001</I>
! 9: <BR><I>Last updated, January 17, 2001</I>
1.2 harris41 10: <OL>
11: <LI><A HREF="#Using_CVS">Using CVS</A>
12: <UL>
13: <LI><A HREF="#cvslog">Logging in and out (cvs login; cvs logout)</A>
14: <LI><A HREF="#cvsget">Getting files (cvs update -d)</A>
15: <LI><A HREF="#cvsupdate">Updating files (cvs update -d)</A>
16: <LI><A HREF="#cvssave">Saving files (cvs commit)</A>
17: <LI><A HREF="#cvsadd">Adding files (cvs add)</A>
18: <LI><A HREF="#cvsadddir">Adding directories (cvs add/import)</A>
19: <LI><A HREF="#cvsnotsure">What to do when you're not sure about your files (cvs update)</A>
20: </UL>
21: <LI><A HREF="#makeHTML">Viewing the software (make HTML)</A>
22: <LI><A HREF="#makebuild">Compiling the software (make build)</A>
23: <LI><A HREF="#loncapafiles">Adding/removing files from the LON-CAPA installation (doc/loncapafiles/loncapafiles.html)</A>
24: <LI><A HREF="#configversusnonconfig">Configurable files versus non-configurable files</A>
25: <LI><A HREF="#makeinstall">Updating the non-configurable files on your machine (make install)</A>
26: <LI><A HREF="#makeconfiginstall">Updating the configurable files on your machine (make configinstall)</A>
27: <LI><A HREF="#makeRPM">Building RPMs (make RPM)</A>
28: </OL>
29:
30: <OL>
31: <A NAME="Using_CVS">
32: <LI><H2>Using CVS</H2>
1.1 harris41 33: <UL>
1.2 harris41 34: <LI><A NAME="cvslog">
35: <H3>Using CVS: Logging in and out (cvs login; cvs logout)</H3>
36: <LI><A NAME="cvsget">
37: <H3>Using CVS: Getting files (cvs update -d)</H3>
38: <LI><A NAME="cvsupdate">
1.4 harris41 39: <H3>Using CVS: Updating files (cvs update -d)</H3>
1.2 harris41 40: <LI><A NAME="cvssave">
1.4 harris41 41: <H3>Using CVS: Saving files (cvs commit)</H3>
1.2 harris41 42: <LI><A NAME="cvsadd">
1.4 harris41 43: <H3>Using CVS: Adding files (cvs add)</H3>
1.2 harris41 44: <LI><A NAME="cvsadddir">
1.4 harris41 45: <H3>Using CVS: Adding directories (cvs add/import)</H3>
1.2 harris41 46: <LI><A NAME="cvsnotsure">
1.4 harris41 47: <H3>Using CVS: What to do when you're not sure about your files (cvs update)</H3>
1.1 harris41 48: </UL>
1.2 harris41 49: <LI><A NAME="makeHTML">
1.3 harris41 50: <H2>Viewing the software (make HTML)</H2>
1.5 harris41 51: <STRONG>Commands</STRONG>
52: <FONT COLOR="#008800">
53: <PRE>
54: cd loncom/build
1.8 harris41 55: rm -Rf HTML <I>(or alternatively, "make clean")</I>
1.5 harris41 56: make HTML
57: cd HTML
58: <I>(look at the index.html file with a web browser such as Netscape)</I>
59: </PRE>
60: </FONT>
1.6 harris41 61: <STRONG>General description of what happens</STRONG>
62: <P>
63: This is the actual make target code.
64: <FONT COLOR="#880000">
65: <PRE>
66: <!-- LONCAPA MAKETARGET=HTML START -->
67: HTML:
68: install -d HTML
69: cp ../../doc/loncapafiles/*.gif HTML
1.7 harris41 70: perl parse.pl ../../doc/loncapafiles/loncapafiles.html HTML > HTML/index.html
1.6 harris41 71: <!-- LONCAPA MAKETARGET=HTML END -->
72: </PRE>
73: </FONT>
1.7 harris41 74: What basically happens is that specially marked-up data in the LON-CAPA
75: cvs repository file <TT>doc/loncapafiles.html</TT> is parsed into a more
76: viewable format by <TT>loncom/build/parse.pl</TT>. The resulting
77: file gives a very well organized view of all the files, directories,
78: links, ownerships, permissions, and brief documentation of what each
79: file does.
1.6 harris41 80: </P>
1.2 harris41 81: <LI><A NAME="makebuild">
1.3 harris41 82: <H2>Compiling the software (make build)</H2>
1.8 harris41 83: <STRONG>Commands</STRONG>
84: <FONT COLOR="#008800">
85: <PRE>
86: cd loncom/build
1.9 harris41 87: make build
1.8 harris41 88: </PRE>
89: </FONT>
90: <STRONG>General description of what happens</STRONG>
91: <P>
92: This is the actual make target code.
93: <FONT COLOR="#880000">
94: <PRE>
95: <!-- LONCAPA MAKETARGET=HTML START -->
96: build:
97: perl parse.pl ../../doc/loncapafiles/loncapafiles.html build > Makefile.build
98: make -f Makefile.build all
99: <!-- LONCAPA MAKETARGET=HTML END -->
100: </PRE>
101: </FONT>
102: <TT>loncom/build/parse.pl</TT> reads in all the build information out
1.10 harris41 103: of <TT>doc/loncapafiles/loncapafiles.html</TT>. A new Makefile named
1.8 harris41 104: <TT>loncom/build/Makefile.build</TT> is dynamically constructed.
105: This dynamically generated Makefile is then run to build/compile
106: all the software targets from source. This currently takes 10 minutes
107: (depends on the speed of the machine you compile with).
108: </P>
109: <STRONG>Example</STRONG>
110: <P>
111: Here is information for one file <TT>tth.so</TT> provided in
112: <TT>doc/loncapafiles/loncapafiles.html</TT>.
1.9 harris41 113: <FONT COLOR="#330066">
1.8 harris41 114: <PRE>
115: <BR><METAGROUP>
116: <BR><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">
117: <BR><DESCRIPTION>
118: <BR>shared library file for dynamic loading and unloading of TeX-to-HTML functionality
119: <BR></DESCRIPTION>
120: <BR><BUILD>
121: <BR>loncom/modules/TexConvert/tthperl/commands
122: <BR></BUILD>
123: <BR><DEPENDENCIES>
124: <BR>../tthdynamic/tthfunc.c
125: <BR>../ttmdynamic/ttmfunc.c
126: <BR></DEPENDENCIES>
127: </PRE>
128: </FONT>
129: <TT>loncom/build/parse.pl</TT> sees the <B>BUILD</B> tags and sets up
130: a dynamic file <TT>Makefile.build</TT> to run the command inside the
131: <B>BUILD</B> tags (currently, <B>DEPENDENCIES</B> is not used for anything
132: besides documentation).
133: </P>
134: <P>
135: Here is an example of a dynamically generated <TT>Makefile.build</TT>
1.11 harris41 136: that builds two LON-CAPA files (one of which is <TT>tth.so</TT>).
1.9 harris41 137: <FONT COLOR="#330066">
1.8 harris41 138: <PRE>
139: all: ../homework/caparesponse/capa.so ../modules/TexConvert/tthperl/tth.so
140:
141: ../homework/caparesponse/capa.so: ../homework/caparesponse/caparesponse.c ../ho
142: mework/caparesponse/caparesponse.pm alwaysrun
143: cd ../homework/caparesponse/; sh ./commands
144:
145: ../modules/TexConvert/tthperl/tth.so: ../modules/TexConvert/tthperl/../tthdynam
146: ic/tthfunc.c ../modules/TexConvert/tthperl/../ttmdynamic/ttmfunc.c
147: cd ../modules/TexConvert/tthperl/; sh ./commands
148:
149: alwaysrun:
150: </PRE>
151: </FONT>
152: </P>
1.2 harris41 153: <LI><A NAME="loncapafiles">
1.3 harris41 154: <H2>Adding/removing files from the LON-CAPA installation (doc/loncapafiles/loncapafiles.html)</H2>
1.11 harris41 155: <STRONG>To add and remove (and alter)</STRONG>
1.12 ! harris41 156: <P>
1.11 harris41 157: All that you have to do to alter the behavior of the installation is
158: edit a single file (<TT>doc/loncapafiles/loncapafiles.html</TT>).
159: Adding, removing, and altering files requires proper attention
160: to the syntax of file format of course.
1.12 ! harris41 161: </P>
1.11 harris41 162: <STRONG>File Format</STRONG>
163: <P>
164: The preceding <A HREF=#"makebuild">"make build"</A> documentation
165: gives an example <B>METAGROUP</B> entry describing one particular file.
166: All data within <TT>loncapafiles.html</TT> is specified according
167: to markup tags. The format and syntax of <TT>loncapafiles.html</TT>
168: is currently best described by the HTML documentation code at the beginning of
169: loncapafiles.html (as well as, by example, seeing how various
170: information is coded). All in all, the syntax is quite simple.
171: </P>
172: <STRONG>Philosophy and notes (the thing nobody reads)</STRONG>
173: <P>
174: Packaging the software from CVS onto a machine file system requires many
175: things:
176: <UL>
177: <LI>documenting every component of the software,
178: <LI>handling CVS <U>source</U> to file system <U>target</U> information
179: <LI>handling (according to a hierarchical scheme of grouping) file
180: ownership and permissions,
181: <LI>handling (according to a hierarchical scheme of grouping) directory
182: ownership and permissions,
183: <LI>handling symbolic links
184: <LI>providing for multiple options of installation targets
185: (RedHat versus Debian for instance),
186: <LI>providing for different file ownerships and permissions to apply
187: to the same file,
188: <LI>allowing system software documentation to be automatically generated
189: (see information on <A HREF="#makeHTML">"make html"</A>),
190: <LI>providing information in an easily adjustable form as new demands
191: are made on the software packaging system,
192: <LI>providing software package information (for RPM),
193: <LI>having information in a format that allows for troubleshooting
194: the current status of the machine file system,
195: <LI>allow for changes to the structure of the CVS repository,
196: <LI>and something that is simple enough for any one to immediately work with,
197: without having to learn specifics (or hidden traps) of complicated Makefile's
198: or a new macro language (m4?).
199: </UL>
200: </P>
201: <P>
202: I looked into, and tried, different ways of accomplishing the above
203: including automake and recursive make. The automake system seemed quite
204: complicated (and needlessly so in terms of this project since, by and large,
205: it works to coordinate many different types of build/compilation parameters
206: whereas we are more concerned with installation parameters). Recursive make
207: has significant deficiencies in the sense that not all the information
208: is kept in one place, and there are significant levels of dependency
209: between all the things that must be done to keep software packaging
210: up to date. A particularly convincing article I found when looking into
211: much of this was
212: <A HREF="http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html">
213: "Recursive Make Considered Harmful" by Peter Miller</A>. Complicating
214: matters was, at the time, it was unclear as to what categories
215: of software files we had, and whether or not the directory structure
216: of CVS would remain constant. With an ever-developing directory structure
217: to CVS, I preferred to organize the information on a per-file basis
218: as opposed to a per-directory basis (although there is a successful
219: implementation of a standard big Makefile in <TT>loncom/Makefile</TT>).
220: Additionally, a standard big Makefile assumes certain "normalcy" to
221: the directory structure of different potential operating system directories
222: (RedHat vs. Debian).
223: </P>
224: <P>
225: If you take time to look at loncapafiles.html
226: (and perhaps run the <A HREF="#makeHTML">make HTML</A> command)
227: you will find that the organizing information according to the markup
228: syntax in <TT>loncapafiles.html</TT> is simple. Simple is good.
229: </P>
230: <P>
231: <TT>loncom/build/parse.pl</TT> is the script (invoked automatically
232: by the various targets in <TT>loncom/build/Makefile</TT>) that reads
233: <TT>doc/loncapafiles/loncapafiles.html</TT>. <TT>parse.pl</TT>
234: is capable of reading and returning different types of information
235: from <TT>loncapafiles.html</TT> depending on how <TT>parse.pl</TT>
236: is invoked. <TT>parse.pl</TT> has yet to have introduced new sources
237: of error, and has been tested in quite a number of ways. As with
238: any parser however, I remain paranoid.
239: </P>
240: <P>
241: My regrets with the current system is that <TT>parse.pl</TT> is
242: slow (can take 1 minute to run) and includes a few tidbits of code,
243: specific to the make process, that probably should be in
244: <TT>loncom/build/Makefile</TT>. Additionally, <TT>loncapafiles.html</TT>
245: should have a DTD and all those other good SGML-ish things (and parsing
246: should be done with a real SGML-derived parser).
247: </P>
248: <P>
249: On the plus side, the <TT>parse.pl</TT>-<TT>loncapafiles.html</TT>
250: combination has been working very efficiently and error-free.
251: </P>
1.2 harris41 252: <LI><A NAME="configversusnonconfig">
1.3 harris41 253: <H2>Configurable files versus non-configurable files</H2>
1.12 ! harris41 254: <STRONG>Machine-specific information is the difference</STRONG>
! 255: <P>
! 256: The current list of configurable files for the LON-CAPA system is
! 257: /etc/httpd/access.conf.
! 258: All of these configurable files contain machine-specific information.
! 259: For instance, the LON-CAPA system relies on unique host IDs such
! 260: as msua3, s1, s2, msul1, and 103a1 (specified as a "PerlSetVar lonHostID"
! 261: field within /etc/httpd/access.conf).
! 262: Non-configurable files simply do NOT have machine-specific information.
! 263: <STRONG>The impact on updating software</STRONG>
! 264: <P>
! 265: What this means in terms of software updating is that
! 266: <UL>
! 267: <LI>non-configurable files can be simply overwritten with newer versions
! 268: (without "anything" else to worry about),
! 269: <LI>and configurable files must follow these steps to be safely overwritten
! 270: <OL>
! 271: <LI>have their machine specific information saved,
! 272: <LI>be overwritten, and then
! 273: <LI>have their machine specific information restored.
! 274: </UL>
! 275: </P>
1.2 harris41 276: <LI><A NAME="makeinstall">
1.3 harris41 277: <H2>Updating the non-configurable files on your machine (make install)</H2>
1.12 ! harris41 278:
! 279:
1.2 harris41 280: <LI><A NAME="makeconfiginstall">
1.3 harris41 281: <H2>Updating the configurable files on your machine (make configinstall)</H2>
1.12 ! harris41 282:
! 283:
1.2 harris41 284: <LI><A NAME="makeRPM">
1.3 harris41 285: <H2>Building RPMs (make RPM)</H2>
1.2 harris41 286: </OL>
1.11 harris41 287: </BODY>
288: </HTML>
1.12 ! harris41 289:
! 290:
! 291:
! 292:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to readme.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [LON-CAPA] / loncom / build