Chapter 1 use for the type when ramlisting"> fetch: :fetch {fetch = cvs://} $source </pre></td></tr></table><p> If you decided to checkout only part of a module, and want to be able to get the rest later, you need to tell where in the module of the file can be found. This is done by adding a "path" attribute to the cvs:// item in the fetch attribute. Example: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> fetch: :fetch {fetch = $CVSROOT {path = mymodule/foo}} foo.aap </pre></td></tr></table><p> What will happen is that aap will checkout "mymodule/foo/foo.aap", while standing in two directories upwards. That's required for CVS to checkout the file correctly. Note: this only works as expected if the recipe is located in the directory "mymodule/foo"! </p><p> If the "path" attribute is omitted, A-A-P will obtain the information from the "CVS/Repository" file. This only works when something in the same directory was already checked out from CVS. </p><h2><a name="id2991870"></a>Checking In</h2><p> When you have made changes to your local project files and want to upload them all into the CVS repository, you can use this command: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> :reviseall </pre></td></tr></table><p> You must make sure that _ALL_ files in the current directory and below that you want to appear in CVS have the "commit" attribute, and no others! Files that were previously not in CVS will be added ("cvs add file") and that exist in CVS but don't have a "commit" attribute are removed ("cvs remove file"). Then all files are committed ("cvs commit file"). </p><p> For CVS you need to mark binary files specifically, otherwise checking out may result in a wrong file (esp. on MS-Windows). In Aap this is done by adding the "binary" attribute to binary files. Example: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> Files = main.c version.c logo.png {binary} </pre></td></tr></table><p> To be able to commit changes you made into the CVS repository, you need to specify the server name and your user name on that server. Since the user name is different for everybody, you must specify it in a recipe in your ~/.aap/startup/ directory. For example: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> CVSUSER_AAP = foobar </pre></td></tr></table><p> The name of the variable starts with "CVSUSER" and is followed by the name of the project. That is because you might have a different user name for each project. </p><p> The method to access the server also needs to be specified. For example, on SourceForge the "ext" method is used, which sends passwords over an SSH connection for security. The name used for the server then becomes: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> :ext:$CVSUSER_AAP@cvs.a-a-p.sf.net:/cvsroot/a-a-p </pre></td></tr></table><p> You can see why this is specified in the recipe, you wouldn't want to type this for commiting each change! </p><h2><a name="id2991927"></a>Distributing Your Project With CVS</h2><p> This is a short how-to that explains how to start distributing a set of files (and directories) using CVS. </p><div class="orderedlist"><ol type="1"><li><p> Copy the files you want to distribute to a separate directory </p><p> Mostly you have various files in your project for your own use that you don't want to distribute. These can be backup files and snippets of code that you want to keep for later. Since the cvs command below imports all files it can find, you need to have a directory tree with exactly those files you want to store in CVS. Best is to to make a copy of the project. On Unix: </p><div class="literallayout"><p> cp -r projectdir tempdir<br> </p></div><p> Then delete all files you don't want to distribute. Be especially careful to delete "AAPDIR" directories and hidden files (starting with a dot). It's better to delete too much than too few: you can always add files later. </p></li><li><p> Import the project to the CVS repository </p><p> Move to the newly created directory ("tempdir" in the example above). Import the whole tree into CVS with a single command. Example: </p><div class="literallayout"><p> cd tempdir<br> cvs -d:ext:myname@cvs.sf.net:/cvsroot/myproject import mymodule myproject start<br> </p></div><p> Careful: This will create at least one new directory "mymodule", which you can't delete with CVS commands. This will create the module "mymodule" and put all the files and directories in it. If there are any problems, read the documentation available for your CVS server. </p></li><li><p> Checkout a copy from CVS and merge </p><p> Move to a directory where you want to get your project back. Create the directory "myproject" with this example: </p><div class="literallayout"><p> cvs -d:ext:myname@cvs.sf.net:/cvsroot/myproject checkout mymodule<br> </p></div><p> You get back the files you imported in step 2, plus a bunch of "CVS" directories. These contain the administration for the cvs program. Move each of these directories back to your original project. Example: </p><div class="literallayout"><p> mv myproject/CVS projectdir/CVS<br> mv myproject/include/CVS projectdir/include/CVS<br> </p></div><p> If you have many directories, one complicated command does them all: </p><div class="literallayout"><p> cd myproject<br> find . -name CVS -exec mv {} ../projectdir/{} \;<br> </p></div><p> This is a bit tricky. Another method is to copy all the files from your original project into the newly created directory. But then you have to be careful not to change relevant file attributes, which is tricky as well. Obviously, the best solution is to have all files you need in CVS, so that you don't have to copy any files. </p></li><li><p> Commit changes </p><p> After making changes to your project and testing them, it's time to check them in. In the recipe you use for building, add a "commit" attribute to all the files that should be in CVS. The <a href="ref-commands.html#cmd-reviseall">:reviseall</a> command then does the work for you (see above). Example: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> Files = $source $header main.aap :attr {commit = cvs://:ext:$CVSUSER_MYPROJECT@cvs.sf.net:/cvsroot/myproject} $Files :reviseall </pre></td></tr></table><p> Careful: $Files must contain all files that you want to publish in this directory and below. If $Files has extra files they will be added in CVS. Files missing from $Files will be removed from CVS. </p><p> You must assign $CVSUSER_MYPROJECT your user name on the CVS server. Usually you do this in one of your personal A-A-P startup files, for example "~/.aap/startup/main.aap". </p></li></ol></div><h2><a name="id2993651"></a>Using Sourceforge</h2><p> If you are making open source software and need to find a place to distribute it, you might consider using SourceForge. It's free and relatively stable. They provide http access for your web pages, a CVS repository and a server for downloading files. There are news groups and maillists to support communication. Read more about it at http://sf.net. </p><p> Since you never know what happens with a free service, it's a good idea to keep all your precious work on a local system and update the files on SourceForge from there. If several people are updating the SourceForge site, either make sure everyone keeps copies, or make backup copies (at least weekly). </p><p> You can use A-A-P recipes to upload your files to the SourceForge servers. To avoid having to type passwords each time, use an ssh client and put your public keys in your home directory (for the web pages) or on your account page (for the CVS server). Read the SourceForge documentation for how to do this. </p><p> For uploading web pages you can use a recipe like this: </p><table border="0" bgcolor="#E0E0E0" width="100%"><tr><td><pre class="programlisting"> Files = index.html download.html news.html images/logo.gif :attr {publish = rsync://myname@myproject.sf.net//home/groups/m/my/myproject/htdocs/%file%} $Files </pre></td></tr></table><p> Start this recipe with the "publish" target. If you don't have the "rsync" command you might want to use "scp" instead. The effect is the same, but "rsync" works more efficient. </p><p> For sourceforge, set environment variable CVS_RSH to "ssh". Otherwise you won't be able to login. Do "touch ~/.cvspass" to be able to use "cvs login" Upload your ssh keys to your account to avoid having to type your password each time. </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="user-version.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="user-issue.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 18. Version Control </td><td width="20%" align="center"><a accesskey="h" href="index.html"> Contents</a></td><td width="40%" align="right" valign="top"> Chapter 20. Issue Tracking</td></tr></table></div></body></html> ��./usr/share/doc/aap-doc/html/user-debug.html��0000644�0000000�0000000�00000011556�10151434256�021042� 0��ustar �root��root��0000000�0000000��<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 26. Debugging a Recipe

Chapter 26. Debugging a Recipe

The log file shows what happened while A-A-P was executing. Often you can figure out what went wrong by looking at the messages.

The log file is named "AAPDIR/log". It is located in the directory of the main recipe. If you executed aap again and now want to see the previous log, it is named "AAPDIR/log1". Older logs are "AAPDIR/log2", "AAPDIR/log3", etc. This goes up to "AAPDIR/log9".

Messages

The kind of messages given can be changed with the MESSAGE variable. It is a comma separated list of message types for which the message is displayed. Other messages are still written in the log file.

name	display message for
all	everything
error	errors (Aap cannot continue)
warning	warnings (things that are wrong but Aap can still continue)
note	notes (warnings about things that are probably OK)
depend	dependencies, the reasoning about what to build
info	general info (file copy/delete, up/downloads)
extra	extra info (why something was done)
system	system (shell) commands that are executed
result	the result of system (shell) commands
changedir	changing directories

The command line arguments "-v" and "-s" can be used to make the most often used selections:

Aap argument	$MESSAGE value
(nothing)	error,warning,system,info
-v	all
--verbose	all
-s	error
--silent	error

Other values can be assigned at the command line. For example, to only see error and dependency messages:

aap MESSAGE=error,depend (other arguments)

Don't forget that excluding "error" means that no error messages are displayed!

No matter what messages are displayed, all messages are written in the log file. This can be used afterwards to see what actually happened.

Chapter 26. Debugging a Recipe

The log file shows what happened while A-A-P was executing. Often you can figure out what went wrong by looking at the messages.

Messages

name	display message for
all	everything
error	errors (Aap cannot continue)
warning	warnings (things that are wrong but Aap can still continue)
note	notes (warnings about things that are probably OK)
depend	dependencies, the reasoning about what to build
info	general info (file copy/delete, up/downloads)
extra	extra info (why something was done)
system	system (shell) commands that are executed
result	the result of system (shell) commands
changedir	changing directories

The command line arguments "-v" and "-s" can be used to make the most often used selections:

Aap argument	$MESSAGE value
(nothing)	error,warning,system,info
-v	all
--verbose	all
-s	error
--silent	error

Other values can be assigned at the command line. For example, to only see error and

A-A-P home page	A-A-P Recipe Executive
Prev	User Manual	Next

A-A-P home page	A-A-P Recipe Executive
Prev	User Manual	Next

Prev	Up	Next
Chapter 25. Automatic Package Install	Contents	Chapter 27. Differences from make