wb1j+@andrew.cmu.edu (William M. Bumgarner) (04/12/89)
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.eduausting@Apple.COM (Glenn L. Austin) (04/13/89)
In article <oYEdmDy00VQE05PGQI@andrew.cmu.edu> wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: >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. I also had the functions work correctly in the worksheet but not in makefiles if the script that exported the variable was simply run from either another script or from the shell. *THIS IS THE CORRECT WAY FOR MPW SHELL TO WORK* If you want the variables to be available to other scripts, you either have to define them directly from the shell, or make sure that your startup scripts have "EXECUTE scriptname" and not just "scriptname". This was put in just for this eventuality. A make file (and by inference BuildProgram) creates a list of commands that usually are executed as a script. If you are still having problems, type "EXPORT Cincludes.bum" in the shell and then attempting your makefile again -- chances are that it will then work correctly. Make *SURE* that your UserStartup and Startup files EXECUTE other scripts -- not just name the script. If they do, your variables will work fine in the shell but not in other scripts. ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------
wb1j+@andrew.cmu.edu (William M. Bumgarner) (04/13/89)
I tried what you suggested... still doesn't work.
C will correctly evaluate the first path, but not the second:
C -b -n -r <delta>
-I {CIncludes} <delta>
-I {CIncludes.bum} <delta>
CDRef.c
Will find the files in {CIncludes}, but not the ones in {CIncludes.bum}.
BUT
C -b -n -r <delta>
-I {CIncludes.bum} <delta>
-I {CIncludes} <delta>
CDRef.c
Will find the files in {CIncludes.bum}, but not the ones in {CIncludes}.
That is why I think the variables are fine, and it is a bug in C... Why else
would it evaluate one and not the other?
the variable is exported from with userstartup(dot)bum... I tried exporting
it and specifically executing the .makeout file... no change, still
didn't find {CIncludes.bum} (either in the source or the makefile stuff).
b.bum
wb1j+@andrew.cmu.eduech@pegasus.ATT.COM (Edward C Horvath) (04/14/89)
From article <EYF3igy00UofI62lVV@andrew.cmu.edu>, by wb1j+@andrew.cmu.edu (William M. Bumgarner): > I tried what you suggested... still doesn't work. > C will correctly evaluate the first path, but not the second: > C -b -n -r <delta> > -I {CIncludes} <delta> > -I {CIncludes.bum} <delta> > CDRef.c > Will find the files in {CIncludes}, but not the ones in {CIncludes.bum}. This is a case of RTFM, I'm afraid: -i takes a comma-separated list; try C ... -i {CIncludes},{CIncludes.bum} ... If you don't have the MPW C manual, try whomever you got the disk from... =Ned Horvath=