Some simple questions

[Brian Rice]

In article <1989Nov27.114301.2440 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:
>In article <21408 at usc.edu>, rkumar at buddha.usc.edu (Anon) writes:
>> 2) Suppose that a text file f is being included (e.g., #include)
>> 	in more than one source. What is, if there is, a mechanism to
>> 	protect file f from being accidentally deleted/modified?
>The best solution would be to have a separate include directory wherein
>this file is placed and never removed (similar to /usr/include).

The -I flag to the C compiler can help; it specifies a directory to look
for include files.  This means that if you had an include file called
wilbur.h, you could put it in your own personal include directory, say,
/usr/users/rkumar/include.  Then your source code would just have

	#include "wilbur.h"

and your makefile would contain lines like

	cc -c kludge.c -I/usr/users/rkumar/include

I think that this solution is the one with the greatest long-term payoff.
The trouble with links is that they hide information in an undesirable
way.  If joe/a.h and jane/a.h are links to the same file, the only ways 
a naive observer has of knowing that changes to joe/a.h will appear in 
jane/a.h are 
      (1) making such a change and encountering the possibly 
          unwanted consequences, or 
      (2) having a paranoid outlook and the ls -il command.  
In a software engineering project, a safer practice is to have only one 
name for the header file and to document various modules' dependencies 
on it in a makefile, as above.

Brian Rice   rice at dg-rtp.dg.com   (919) 248-6328
DG/UX Product Assurance Engineering
Data General Corp., Research Triangle Park, N.C.
"My other car is an AViiON."