CPP include functionality; am I dreaming or could this work?

Mario Nigrovic; RVVK40 Mario.Nigrovic@Motorola.com
Tue Dec 16 00:17:00 GMT 2003


Hi -

    I really prefer to build all my binaries from read-only source trees, so
I can be absolutely certain of reproducable behavior.  To this end, I take
advantage of VPATH with modern GNU make and configure.

    But sometimes packages have problems with this -- either they're broken
or they like to create alternate text files for internationalization -- so
I also sometimes bodily copy the "read only" tree onto /tmp (where I'm
building) so that I can do a ./configure and again not disturb the source.

    Ok, enough background.  Sometimes copying the whole source takes a lot
of time and I think why bother if only one or two files needs updating.  It
sort of makes sense that if I copy those files into the /tmp hierarchy that
make/gcc would find them there instead.  This works, unless the file is a
header file, because gcc finds the file at $VPATH rather than the one in
/tmp.

    So what I'm asking is, is there some way to let cpp know that it's
working in this funky VPATH-driven mode, and that it needs to consider the
current directory for included files before the directory the file is
actually found in?  While conceptually simple, there is acutally some
challenge involved if the file would not be in ".".  In my current setup
(where I'm having the problem of different .c files see different versions
of the .h file), I've verified that the only difference between the two
gcc commands is the path to the file.  The files are identical.  I think
that the trick would be to substitute $VPATH in the .c file's path with
"." and see if the included file is there.

					Mario
-- 
Whoever fights monsters should see  |            Mario.Nigrovic@Motorola.Com
to it that in the process he does   | EL518/2100 E. Elliot Rd/Tempe AZ 85284
not become a monster.  -- Nietzsche |     desk:480/413-3578 pgr:602/261-9454



More information about the Gcc-help mailing list