>Number: 5428 >Category: general >Synopsis: Release should contain a TAGS file, or means of creating one >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: support >Submitter-Id: apache >Arrival-Date: Mon Dec 6 10:50:01 PST 1999 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: >Environment: Linux >Description: It would be very nice if the source code release either contained a TAGS file (preferably generated in etags format), or a shellscript that might indicate how to create one. Several of the source code files make use of macros which make it very difficult to use etags to generate fully useful TAGS files. For example, main/util_script.c contains declarations of the form:
API_EXPORT(void) functionIdentifier(....) where API_EXPORT is a macro that evaluates to "void" (I assume). When etags scans this line it sees API_EXPORT as the declared function, and not functionIdentifier. >How-To-Repeat: API_EXPORT(void) ap_log_rerror(....) >Fix: Build the TAGS file with something like (all on one line): etags --regex='/[A-Z_]*_EXPORT(\(.*\))[ \t]*\([A-Za-z_0-9]*\) (/\1 \2/' ap/*.[ch] main/*.[ch] modules/proxy/*.[ch] modules/standard/*.[ch] mod ules/experimental/*.[ch] support/*.[ch] os/unix/*.[ch] regex/*.[ch] >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, you need] [to include <[EMAIL PROTECTED]> in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]
