[jamming] Confusion with overloaded ctype.h

Roger.Shimada at lawson.com Roger.Shimada at lawson.com
Thu Feb 19 09:17:07 PST 2004


We have a program called mkhdr which basically converts a .c to a .h.
(And thanks to Randy Roesler for finding my incorrect MakeLocate!)

We also rolled our own internationalization.  Unfortunately we were
lazy about it and created our own ctype.h.

On a clean build, we need to build both mkhdr and ctype.h.

mkhdr requires the standard ctype.h.  So for this I did a "HDRS = ;".

But in a stituation when Jam needs to build both mkhdr and our ctype.h,
I get:

...updating 5 target(s)...
LawMkHdr1 /bld/univ/include/ctype.h 
/bin/sh[3]: mkhdr:  not found.

        cd univ/src/lib/stdlaw
        mkhdr -g ctype.c

...failed LawMkHdr1 /bld/univ/include/ctype.h ...
...skipped <univ!src!local>mkhdr.o for lack of <univ!src!local>mkhdr.c...
...skipped mkhdr for lack of <univ!src!local>mkhdr.o...
...failed updating 1 target(s)...
...skipped 2 target(s)...

a "jam -d6 | grep ctype.h" includes:

>>>> Includes <univ!src!local>mkhdr.c  : io.h unistd.h stdio.h fcntl.h 
sys/types
.h sys/stat.h ctype.h string.h stdlib.h errno.h 
>>>> set SEARCH on io.h unistd.h stdio.h fcntl.h sys/types.h sys/stat.h 
ctype.h 
string.h stdlib.h errno.h  = univ/src/local /usr/include 

I fumbled around in the debugger for awhile, and it looks like search() 
finds
ctype.h via LOCATE.  This would be cool if the LOCATE matched SEARCH, 
which it
doesn't when building mkhdr.

Any ideas asides from renaming our ctype.h?  (We're also multiplatform, so
changing mkhdr to do an #include </usr/include/ctype.h> won't work 
either.)

My love/hate relationship with Jam continues....

--
Roger Shimada - Software Architect
Lawson Software                     Phone: +1-651-767-4610
380 St. Peter Street               e-mail: roger.shimada at lawson.com
St. Paul, MN  55102  USA           AOL IM: rshimada



More information about the jamming mailing list