[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:USG buildhelp questions/answers
Moderator:SMURF::FILTER
Created:Mon Apr 26 1993
Last Modified:Mon Jan 20 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2763
Total number of notes:5802

1610.0. "Re: bogus identifier strings in dxlsm" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Jul 18 1995 13:51

Date Of Receipt: 	18-JUL-1995 12:29:46.56
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  18-Jul-1995 1228"
To: 	slrundba@DEC:.zko.flume
CC: 	jmf@DEC:.zko.flume, mcguirk@DEC:.zko.flume, odehelp@DEC:.zko.flume,
	buildhelp@DEC:.zko.flume
Subj: 	Re: bogus identifier strings in dxlsm

Susan, as of gold (v3.0) the header format was changed for .c files
from that listed in

    /usr/sde/osf1/headers.v20/header.c :

	#ifndef lint
	static char *rcsid = "@(#)$RCSfile$ $Revision$ (DEC) $Date$";
	#endif

to that listed in the default location

    /usr/sde/osf1/headers/header.c :

	#pragma ident "@(#)$RCSfile$ $Revision$ (DEC) $Date$"

In a file that's been bco'd or bsubmit'd, the values of the 3 rcs variables
get filled in.

For header files or scripts the information is put in a comment, eg
in header.h:
	/*
	 * @(#)$RCSfile$ $Revision$ (DEC) $Date$
	 */

These header files are the starting point for new files created with bcreate,
but they can be used also to cut/paste into existing files.

The sccs "what" command just keys off of the @(#), which should appear
just once for any line with the $RCSfile$ etc.  In some cases, as in
your two examples:

    /* @(#)@(#)src/analUtil.c       2.1 20 May 1993 13:19:49 -  */

    #ident  "@(#)va11:cmd/vxva/analUtil.c   2.1"

The variables were dropped out - and only a hardcoded version remains
(probably an old version from when sccs was used for the pool in "tin").
This means that these values can never be correct for our pool.

These generally serve no purpose and should be either removed, or at
least the @(#) should be removed so that 'what' won't pick them up.  In
a few cases developers want to track the revs from the "import" source;
in that case these revs might make sense as internal code
documentation, but again the @(#) should be removed from these lines
since they are not the DEC versions.

Each source file should have exactly one line tagged with @(#).

Hope this answers your questions...  (Note I've cc'd odehelp as an fyi)

		-josh


> 
> Hello! I started working in the LSM group a couple of months ago.
> 
> A QAR (34011) was assigned to me regarding bogus identifier strings in dxlsm.
> Bob McGuirk suggested I talk to you about this as I'm not sure how to fix the
> problem. RCS stuff is quite new to me!
> 
> The dxlsm files include the following type of info:
> 
> ifndef lint
> static char *rcsid = "@(#)$RCSfile: analUtil.c,v $ $Revision: 1.1.5.2 $ (DEC) 
> $Date: 1995/04/28 18:54:13 $";
> #endif
> /* @(#)@(#)src/analUtil.c       2.1 20 May 1993 13:19:49 -  */
> #ident  "@(#)va11:cmd/vxva/analUtil.c   2.1"
> 
> Apparantly, the #ident string is bogus, meaning you cannot use what(1) to map a
> source revision to an object module. It needs to be updated to use the DEC
> identifier. Where can I get some more info. about this? Is this simply a matter 
> of using a different syntax for the #ident line, or are there more issues to 
> consider? Do I need both the rcsid and ident line?
> 
> Thanks!
> 
> Susan Rundbaken





T.RTitleUserPersonal
Name
DateLines