home *** CD-ROM | disk | FTP | other *** search
/ Dream 57 / Amiga_Dream_57.iso / Amiga / Programmation / c / Docs / cxref-1.4a.lha / FAQ < prev    next >
Encoding:
Text File  |  1997-06-22  |  17.9 KB  |  463 lines

  1.           CXREF VERSION 1.4 - FREQUENTLY ASKED QUESTIONS AND ANSWERS
  2.           ==========================================================
  3.  
  4. This file contains a list of frequently asked questions and their answers
  5. relating to cxref version 1.4.
  6.  
  7. Not all of the questions here are real users questions, some of them have been
  8. made up to give some help to people trying to use the program who find that the
  9. README documentation is insufficient.
  10.  
  11. --------------------------------------------------------------------------------
  12.  
  13. Section 0 - Why doesn't this FAQ answer my question?
  14.  
  15. --------------------
  16.  
  17. Section 1 - What does cxref do (and what it doesn't)
  18.  
  19. Q 1.1   Does cxref support C++?
  20. Q 1.2   Does cxref show which #includes that are not needed?
  21. Q 1.3   Can cxref document automatic function variables?
  22. Q 1.4   Does cxref run on systems other than UNIX?
  23.  
  24. --------------------
  25.  
  26. Section 2 - When cxref does not work
  27.  
  28. Q 2.1a  How do I find out what is causing the parse error?
  29. Q 2.1b  What does this parse error message mean?
  30. Q 2.2   Where are files doc/cxref.html & FAQ.html referenced from README.html?
  31. Q 2.3   Why are half of the cross references missing?
  32. Q 2.4   Why can't cxref process my header file in isolation?
  33. Q 2.5   Why can't LaTeX process the output files?
  34. Q 2.6   Why does the include file name have the complete path name?
  35.  
  36. --------------------
  37.  
  38. Section 3 - How to make cxref do what you want
  39.  
  40. Q 3.1   How do I use cxref to process source files in more than one directory?
  41. Q 3.2   How can I add my own information to the output files?
  42. Q 3.3   Can I get a subset of the cross-reference information?
  43. Q 3.4   Is there an easy way to generate the comments in the correct format?
  44. Q 3.5   How do I produce LaTeX output from a single source.c.tex output file?
  45. Q 3.6   How can I pass extra arguments to the C pre-processor?
  46. Q 3.7   Can I cross-reference my source code at the same time as compiling it?
  47. Q 3.8   What use is the .cxref configuration file?
  48.  
  49. --------------------
  50.  
  51. Section 4 - More information about cxref
  52.  
  53. Q 4.1   Who wrote cxref, When and Why?
  54. Q 4.2   How do I report bugs in cxref?
  55.  
  56. --------------------------------------------------------------------------------
  57.  
  58. Section 0 - Why doesn't this FAQ answer my question?
  59.  
  60. This FAQ is released with each new version of the cxref program, so if the
  61. question is one that is frequently asked about the new version then you will by
  62. definition not find the answer here.
  63.  
  64. You can find the latest information about cxref at the cxref web-page, this
  65. contains among other things a list of bug-fixes for the latest version.
  66.  
  67. http://www.gedanken.demon.co.uk/cxref/
  68.  
  69. --------------------------------------------------------------------------------
  70.  
  71. Section 1 - What does cxref do (and what it doesn't)
  72.  
  73. --------------------
  74.  
  75. Q 1.1   Does cxref support C++?
  76.  
  77. No.
  78.  
  79. The cxref program only works for C, More specifically:
  80.  
  81. 1) ANSI standard C with some leniency for common non-ANSI syntax.
  82.         For example, the construct 'switch(foo) { case 1: ... default: }' is not
  83.         ANSI, there must be a ';' after the default label, but it is accepted by
  84.         cxref.
  85.  
  86. 2) Traditional (K&R) function declarations, with implicit 'int' and 'void'.
  87.         For example 'foo(){}' is parsed as if 'int foo(void){}' was specified.
  88.  
  89. 3) The ability to parse GCC extensions.
  90.         The GCC '__attribute__' and '__extension__' keywords and most of the
  91.         other GCC extensions. The 'inline' keyword is allowed.
  92.  
  93. --------------------
  94.  
  95. Q 1.2   Does cxref show which #includes that are not needed?
  96.  
  97. No.
  98.  
  99. The output of the cxref program cross-references all of the functions,
  100. variables, type definitions, included file etc.  There is not a way of
  101. identifying files that are included in another source file that do not need to
  102. be.
  103.  
  104. --------------------
  105.  
  106. Q 1.3   Can cxref document automatic function variables?
  107.  
  108. No.
  109.  
  110. The inclusion of automatic variables in the output is not included.  This is
  111. because of the number of them in a typical function.  In theory it could be made
  112. to do this.
  113.  
  114. --------------------
  115.  
  116. Q 1.4   Does cxref run on systems other than UNIX?
  117.  
  118. For example DOS / Win3 / Win95 / WinNT / OS/2.
  119.  
  120. UNIX    = Yes
  121.         This is the system that the program way designed and initially written
  122.         for, it should work on many versions of UNIX.
  123.         I know that it works on Linux, SunOS 4.1.x, Solaris 2.x, AIX & HP-UX 10.
  124.  
  125. DOS/Win3 = No
  126.         The program was not designed for DOS, the filenames used and the
  127.         multi-process nature of the program do not allow this.
  128.  
  129. Win95/WinNT = Maybe
  130.         Since Windows 95 and Windows NT claim to be real 32-bit multi-tasking
  131.         operating systems, and support the long filenames that are required, it
  132.         should in theory be possible to get the program working on these.
  133.         I have reports that it is possible, but I do not support cxref for these
  134.         OSes.
  135.  
  136. OS/2    = Maybe
  137.         As for Windows 95 / Windows NT above.
  138.         I have reports that it is possible with OS/2 Warp with emx, but I do not
  139.         support cxref for this OS.
  140.  
  141. --------------------------------------------------------------------------------
  142.  
  143. Section 2 - When cxref does not work
  144.  
  145. --------------------
  146.  
  147. Q 2.1a  How do I find out what is causing the parse error?
  148.  
  149. The following error message is generated by cxref when parsing a source file
  150. (with YYDEBUG set to 0 in parse-yy.h when cxref was compiled).
  151.  
  152. test.c:   4: parse error, expecting `','' or `';''
  153. ^^^^^^  ^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  154. file    line            type of error
  155. name    number        generated by yacc
  156.  
  157. The error is on line 4 of the file test.c.  In this case, the error message that
  158. the yacc parser is generating is of some help, more often the error message is
  159. just 'parse error'.
  160.  
  161. If YYDEBUG was set to 1 in parse-yy.h, then a more detailed error message would
  162. be given (see Q 2.1b).
  163.  
  164.  
  165. Q 2.1b  What does this parse error message mean?
  166.  
  167. The following error message is generated by cxref when parsing a source file
  168. (with YYDEBUG set to 1 in parse-yy.h when cxref was compiled).
  169.  
  170. test.c:   4: parse error, expecting `','' or `';''
  171.  
  172. The previous 10, current and next 10 symbols are:
  173.  -8 | 296 :              INT : int
  174.  -7 | 258 :       IDENTIFIER : foo
  175.  -6 |  40 :                  : (
  176.  -5 | 292 :             VOID : void
  177.  -4 |  41 :                  : )
  178.  -3 | 123 :                  : {
  179.  -2 | 296 :              INT : int
  180.  -1 | 258 :       IDENTIFIER : a
  181.   0 | 296 :              INT : int
  182.   1 | 258 :       IDENTIFIER : b
  183.   2 |  59 :                  : ;
  184.   3 | 125 :                  : }
  185. END OF FILE
  186. ^^^               ^^^^^^^^^^  ^^^^^
  187. symbol              symbol    symbol
  188. number               type     value
  189.  
  190. From this we can reconstruct part of the file test.c, using the previous and
  191. next 10 symbol values from the lexer.
  192.  
  193. int foo(void) { int a   int b; }
  194.                       ^
  195. This is where the parse error occured, after 'int a' and before 'int b;'.
  196. The cause of the error is now clear, there is a ';' missing after the
  197. declaration of the variable a.
  198.  
  199. The cxref program is intended to be used on source files that are known to
  200. compile with a C compiler.  In this case a parse error message should not be
  201. seen except for either non-standard C, (and compiler) or a bug in cxref.
  202.  
  203. --------------------
  204.  
  205. Q 2.2   Where are files doc/cxref.html & FAQ.html referenced from README.html?
  206.  
  207. The README.html file has a reference to the files doc/cxref.html and FAQ.html
  208. these files are only present when 'make docs' has been run to generate the cross
  209. references for the cxref program itself.
  210.  
  211. --------------------
  212.  
  213. Q 2.3   Why are half of the cross references missing?
  214.  
  215. The way that cxref works is that it processes all of the source files for a
  216. program, one at a time and generates a cross reference database.  A second pass
  217. of the program is required to generate all of the cross references from the
  218. database of cross reference information.
  219.  
  220. For this reason, the Makefile for the doc directory of cxref uses 'cxref *.c
  221. -xref -Odoc' for the first pass and 'cxref *.c -xref -Odoc -html -latex' for the
  222. second pass.  The first to build the database, the second to produce the
  223. outputs.
  224.  
  225. The reason that the cross references are missing is that only one pass of the
  226. program has been done on all of the files.  The later files to be be processed
  227. will have cross references for the earlier files processed.
  228.  
  229. --------------------
  230.  
  231. Q 2.4   Why can't cxref process my header file in isolation?
  232.  
  233. The cxref program needs to process the header files to enable a cross reference
  234. for them to be generated.  In many cases, the header file will not have been
  235. written with this in mind, and may rely on other header files being included
  236. before the one being processed.  The only solution to this is to modify the
  237. header file so that it includes all of the header files that it needs.
  238.  
  239. --------------------
  240.  
  241. Q 2.5   Why can't LaTeX process the output files?
  242.  
  243. There are two options for producing LaTeX output, '-latex' and '-latex2e'.
  244. These refer to two different versions of the LaTeX program.  The first is for
  245. use with LaTeX version 2.0.9, the second for use with LaTeX version 2e.
  246.  
  247. The file cxref.tex (or basename.tex if '-Nbasename' is used) is the file that
  248. must be processed by LaTeX.
  249.  
  250. --------------------
  251.  
  252. Q 2.6   Why does the include file name have the complete path name?
  253.  
  254. This is because a standard C preprocessor is being used instead of cxref-cpp.
  255. One of the changes to the GNU cccp to make cxref-cpp is to make it output the
  256. names of the include files as they are in the original source code and not after
  257. the files have been translated into an absolute pathname.
  258.  
  259. --------------------------------------------------------------------------------
  260.  
  261. Section 3 - How to make cxref do what you want
  262.  
  263. --------------------
  264.  
  265. Q 3.1   How do I use cxref to process source files in more than one directory?
  266.  
  267. The cxref program depends on a database of cross references, these must all be
  268. consistent.  This requires that all of the files to be cross referenced are in
  269. the same directory tree.
  270.  
  271. Example:
  272.  
  273. directory     files
  274. - - - - -     - - -
  275. basedir    :  f0.c f0.h ...
  276.  |- s1     :  f1.c f1.h ...
  277.  |- s2     :  f2.c f2.h ...
  278. ...
  279.  
  280. -- f2.c --
  281. #include <...>
  282. #include "f2.h"
  283. #include "../s1/f1.h"
  284. #include "f0.h"
  285. ----------
  286.  
  287. In the base directory 'basedir' run 'cxref -xref -Odoc s2/f2.c -html -I.'.  This
  288. will create the file 'doc/s2/f2.c.html' for the file 'f2.c' and this will
  289. contain references to the files 'doc/s2/f2.h.html', 'doc/s1/f1.h.html' and
  290. 'doc/f0.h.html'.  The subdirectories 'doc/s1', 'doc/s2' will be automatically
  291. created within the 'doc' directory to put the files into (the 'doc' directory
  292. must already exist).
  293.  
  294. directory        files
  295. - - - - -        - - -
  296. basedir
  297.  |- doc       :  f0.c.html f0.h.html ... cxref.html
  298.      |- s1    :  f1.c.html f1.h.html ...
  299.      |- s2    :  f2.c.html f2.h.html ...
  300. ...
  301.  
  302. An alternative method is to use the -R option to cxref.  In the directory 's2',
  303. cxref can be run as 'cxref -R.. -xref -Odoc f2.c -html -I.'.  This will change
  304. directory to '..' ('basedir') before cxref is run, and will modify the cxref
  305. arguments so that it is equivalent to running cxref from 'basedir' as detailed
  306. above.
  307.  
  308. --------------------
  309.  
  310. Q 3.2   How can I add my own information to the output files?
  311.  
  312. The files cxref.html and cxref.tex (depending on whether using HTML or LaTeX
  313. format and the use of the '-Nbasename' option) are the ones to edit.  These
  314. files contain the lines 'Begin-Of-Source-Files' and 'End-Of-Source-Files' as
  315. comments.  The output files for each source file are automatically included
  316. between these lines if they do not already exist there.  The order of these
  317. files and any other text between these lines is not important.  Customisation of
  318. the files should be added here.  The output files for each source file are
  319. automatically generated so any edits made to these will be lost when cxref is
  320. run.
  321.  
  322. --------------------
  323.  
  324. Q 3.3   Can I get a subset of the cross-reference information?
  325.  
  326. At the moment, the only one way to limit the amount of cross referencing is to
  327. use the '-xref-*' command line option (see README).  There are plans for a
  328. future version of cxref to have an options file that would allow different
  329. amounts of information to be generated in the output.  For example, only to
  330. display called and not calls information for each function.
  331.  
  332. --------------------
  333.  
  334. Q 3.4   Is there an easy way to generate the comments in the correct format?
  335.  
  336. The only easy way to do this is to use the cxref.el macro file and Emacs.  This
  337. is what is used to generate the comments in the cxref source code itself.
  338.  
  339. --------------------
  340.  
  341. Q 3.5   How do I produce LaTeX output from a single source.c.tex output file?
  342.  
  343. The file cxref.tex (or basename.tex if '-Nbasename' is used) is the file that
  344. must be processed by LaTeX.  All of the individual LaTeX files for the source
  345. files are included into this file.  If an individual file source.c.tex needs to
  346. be processed then a copy of the file cxref.tex should be modified to include
  347. only the required source.c.tex file.
  348.  
  349. --------------------
  350.  
  351. Q 3.6   How can I pass extra arguments to the C pre-processor?
  352.  
  353. The cxref program itself has three ways that you can specify the arguments that
  354. are passed to the C pre-processor.
  355.  
  356. a) The -CPP option allows the name of the pre-processor program itself to be
  357.    changed.
  358.    e.g. 'cxref -CPP "/usr/foo/cpp -C" foo.c' will use the cpp from /usr/foo
  359.    instead of the compiled in default and pass it the option -C.
  360.  
  361. b) The most common C pre-processor commands are recognised by cxref
  362.    automatically, these are -D*, -U* and -I*.
  363.  
  364. c) Any amount of extra options can be passed to the preprocessor by appending
  365.    them to the command line after the end-of-arguments marker '--'.
  366.    e.g. 'cxref foo.c -- -traditional' will pass -traditional to the
  367.    pre-processor.
  368.  
  369. A useful argument that you may want to use is '-- -include filename.h' This will
  370. include the specified file into the source file that is being processed at the
  371. beginning, and can be used to help when processing header files that do not
  372. include all of the required definitons (See Q 2.4).
  373.  
  374. --------------------
  375.  
  376. Q 3.7   Can I cross-reference my source code at the same time as compiling it?
  377.  
  378. It is possible to cross-reference and document your source code at the same time
  379. as compiling it by using the cxref-cc script.  This takes the same arguments as
  380. your usual C compiler and performs both functions.
  381.  
  382. First it calls the C compiler and passes on all of the command line arguments.
  383. The real C compiler is specified by the CXREFCC environment variable, or the CC
  384. environment variable or it will use gcc if neither of these are set.
  385.  
  386. Second the arguments that cxref needs to have are extracted from the arguments
  387. that the C compiler had and cxref is called.  The arguments that are kept are
  388. the -D*, -U*, -I* arguments to specify #defines and #include paths, and the file
  389. name of the source file itself.  Any other arguments are taken from the .cxref
  390. file (See Q 3.8).
  391.  
  392. After doing this it will still be necessary to sort out the header files since
  393. these are not cross-referenced using this method.
  394.  
  395. --------------------
  396.  
  397. Q 3.8   What use is the .cxref configuration file?
  398.  
  399. The most obvious use is if you have a lot of command line options that you don't
  400. want to have to enter every time that you run the program.
  401.  
  402. However the .cxref file is most useful when you have a multiple directory source
  403. tree (See Q 3.1), or when you are using an existing Makefile to build
  404. documentation.
  405.  
  406. When there are various subdirectories containing source code, a .cxref file in
  407. each sub-directory can be used just containing the line '-R..' or whatever is
  408. appropriate to point cxref to the root of the source tree.  This means that
  409. there is no need to keep track of which directory you are in, they all will use
  410. the correct directory to work from.
  411.  
  412. If you already have a Makefile that goes through all of the source code then you
  413. may want to modify it so that it calls cxref instead of calling the C compiler.
  414. This means that there is no room to put the extra arguments to cxref on the
  415. command line.  A .cxref file can contain the command line arguments so that you
  416. only need to need the arguments that are already there for the C compiler
  417. (See Q 3.7).
  418.  
  419. --------------------------------------------------------------------------------
  420.  
  421. Section 4 - More information about cxref
  422.  
  423. --------------------
  424.  
  425. Q 4.1   Who wrote cxref, When and Why?
  426.  
  427. The cxref program was written by Andrew M. Bishop (amb@gedanken.demon.co.uk) in
  428. 1995,96,97.
  429.  
  430. There is a cxref home-page on the World Wide Web, available via the author's
  431. home-page at http://www.gedanken.demon.co.uk/.  This is kept updated with news
  432. about the program, as new versions become available.
  433.  
  434. An earlier program by the same author using basically the same comment
  435. convention was written in Emacs Lisp in 1994.  This version was slow, the amount
  436. of cross referencing was poor and the output was only in troff format.  The
  437. current C program was written to replace this but has grown to become much
  438. better in the cross referencing that is done and the format of the output has
  439. increased greatly.
  440.  
  441. The cxref program can be freely distributed according to the terms of the GNU
  442. General Public License (see the file `COPYING').
  443.  
  444. --------------------
  445.  
  446. Q 4.2   How do I report bugs in cxref?
  447.  
  448. By e-mail, send them to me at amb@gedanken.demon.co.uk and put cxref somewhere
  449. in the subject line.  You can also report bugs or provide comments via the
  450. feedback form on the cxref home-page on the World Wide Web accessible via
  451. http://www.gedanken.demon.co.uk/.
  452.  
  453. Before doing this, you should check the FAQ and the cxref web-page to see if the
  454. answer is there.  If it is not, and it is a parse error then check that it is a
  455. cxref problem and not a syntax error in the source file.
  456. When you are sure that it is a cxref bug, give me as much information as you
  457. can, about the error, when it happens, what system you are using etc.  It is
  458. useful if you can provide a small example and the output of using the '-raw'
  459. option to provide the actual output that you are seeing.  (If it is an HTML or
  460. LaTeX specific problem then send that file instead.)
  461.  
  462. --------------------------------------------------------------------------------
  463.