Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!ucsd!orion.cf.uci.edu!uci-ics!venera.isi.edu!raveling
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.lang.c
Subject: Re: Recursive #includes
Message-ID: <7654@venera.isi.edu>
Date: 28 Feb 89 18:15:36 GMT
References: <2532@goofy.megatest.UUCP> <4587@hubcap.UUCP>
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 34

In article <4587@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>From article <2532@goofy.megatest.UUCP>, by djones@megatest.UUCP (Dave Jones):
>> ) Are recursive #includes hazardous to your software's health? 
>
>    Could we move this discussion to comp.lang.c, please?

	I believe it's germane to this group, and should be
	considered one facet of software engineering issues 
	involving structuring and managing source code.  Other
	languages face the same issues.

	Lack of consistency in included source has easily
	demonstrated costs, and should be recognized as a
	software engineering problem.  Consider these 4 consecutive
	lines in my make log for contributed X11R3 software:
	
    MenuBox             Made            Needed to hack includes for test
    Xhp                 Make failed; syntax errors in include files
    Xsw                 Make failed; missing include file
    widgetwrap          Make failed; depends on include file installation


	Problems with included source were the largest cause
	of failures in generating "portable" software in this
	set.  If I search out and fix all such problems in this
	set of source, the cost of my time plus overhead will
	probably be on the order of tens of kilobucks.  Now
	consider a few thousand other people around the country
	doing the same... 


----------------
Paul Raveling
Raveling@isi.edu