Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!lll-crg!lll-lcc!unisoft!fnf
From: fnf@unisoft.UUCP (Fred Fish)
Newsgroups: net.micro.amiga
Subject: Re: Compiling Hack
Message-ID: <27@unisoft.UUCP>
Date: Sat, 8-Mar-86 14:12:12 EST
Article-I.D.: unisoft.27
Posted: Sat Mar  8 14:12:12 1986
Date-Received: Mon, 10-Mar-86 00:05:23 EST
References: <1440@caip.RUTGERS.EDU>
Reply-To: fnf@unisoft.UUCP ()
Organization: UniSoft Systems; Berkeley, CA
Lines: 19

In article <1440@caip.RUTGERS.EDU> dg%DEImos.Caltech.Edu%Hamlet.Caltech.Edu@Jpl-VLSI.ARPA@caip.RUTGERS.EDU writes:
>Next, I found that most modules have include statements such as 
>#include <stdio.h>, whereas they should be #include <lattice/stdio.h>.
>Rather than changing all the modules, I solved this problem by copying 
>the include:lattice files to include:.

The prefered way to deal with this situation if to leave the source code
alone (#include <stdio.h> is right) and tell the compiler where to look
for the files.  Manx C got this right and put stdio.h, along with some
other "standard" header files, in the <something>:include directory, rather
than in their own non-standard <something>:include/<C_compiler_vender>
directory.  Any code that has a line like #include <lattice/foo.h> is going
to be very non-portable!

Off course, you could use my cc frontend, posted to the net a long time
ago, that hides all the Lattice bogosity's from the user, but that is 
another story...

-Fred