Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!andrew.cmu.edu!wb1j+
From: wb1j+@andrew.cmu.edu (William M. Bumgarner)
Newsgroups: comp.sys.mac.programmer
Subject: C -I bug in MakeFile's...
Message-ID: <oYEdmDy00VQE05PGQI@andrew.cmu.edu>
Date: 12 Apr 89 00:47:11 GMT
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 64

Through experimentation, I have concluded that the problem w/-I flag for the
c compiler is a bug and not a product of my own stupidity (though that
possibility hasn't been entirely ruled out).

I slept on it (14 hours) and then tried every permutation of the -I that I
could think of (including the ones reccommended on the net and the one
in the documentation).

Settings/Variables/Environments:

{CIncludes.bum} is a valid path to my custom/special include files.  It is
defined and export'ed in UserStartup(dot)bum.  It is valid:
open {CIncludes.bum}CDRom.h
opens the file CDRom.h in the specified directory.

The problem:

in the makefile, I have:

.c.o (from) .c
  c -b -n -r {Default}.c  w/each .c file that uses a custom include having
the full, unaliased pathname and the filename... this works fine, but will be
a real pain if I move anything around....
What I want to do, which should, but won't work:

c -b -n -r (delta)
  -I {CIncludes.bum} (delta)
  -I {CIncludes} (delta)
  {Default}.c

or

c -b -n -r (delta)
  -I {CIncludes},{CIncludes.bum} (delta)
  {Default}.c

The first is as suggested by someone, the second is as documented in the
manual.

Both work when selected and executed on the worksheet, but both fail when
executed in the make file.  In both cases, c has no problem finding the
includes specified in the first parameter, but will not be able to find
those in the second parameter (first case, it wouldn't be able to find the
supplied .h files/second case, it wouldn't find my custom .h files).

Why does this fail in the makefile???
Also:

I thought, "okay, fine, I'll just put the shell variable in the .c files and
have it find them from there".

Nope:

#include <{CIncludes.bum}CDRom.h>

returns a file not found... even though open {CIncludes.bum}CDRom.h works fine.

Do I need to do something special to have the shell variable expanded
properly?  (like the $$shell command for Rez?)

Am confused, but not as incoherent as before....

b.bum
wb1j+@andrew.cmu.edu