RE: hard links vs. sym links

[Greg Spencer]

Gary writes:
> The design goal in question makes sure the compiler finds
> *generated* header files in the way you'd expect.

Well (since I have exactly this scenario), I can attest that it works as
long as you add the build directory to the include path.

For instance, when I build the library that has a generated .h file for
our viewer, I just use the following when I clone the cons environment:

$local = $CONS->clone( CPPPATH => $CONS->{CPPPATH}.";$BUILD/lib/viewer"
);

Where BUILD is an exported variable describing the location of the
linked build hierarchy for this build (which changes depending on
various things, like debug/release builds).  Of course, if you don't
have variant builds (pretty uncommon), you could just specify
"#build/lib/viewer".

Yes, it's ugly and not automatic, but it does work just fine.  And,
given that my working assumption is that the compiler is working on the
files in the source directory, it's not all that unexpected.

I think you're right about running the compiler in the build dir as a
possible solution.  When I looked at that when I was doing my
modifications in the first place, it appeared that a lot of the cons
code relies on the fact that the local directory doesn't change during a
run.  I'm sure this could be fixed by using some perl execution wrapper
to cd to the directory, execute the compiler, and then cd back, but then
all the directory and file paths passed to the compiler on the command
line would have to be modified too, making it a hairy change.  So, I
opted to skip it and just add the build dir to the include path.

                                -Greg.