[Cmake] Setting variables breaks the cache for SUBDIRS?

[Schumacher, Gordon]

Well, as it happens... this issue that Zachary Pincus is exactly the same
one that I've been wrestling with, for exactly the same reasons.  I've been
trying to make the build system modular, so that the top-level makefile only
needs to know about the "modules" - i.e., projects - not the underlying
directory structures.

Someone, William A. Hoffman I think, wondered why one would want to do this?
Well, the reason that I am pushing for this is because right now, we don't
*have* a build system - we've got a cross-platform project that's a mishmash
of Visual Studio 6, DJGPP (DOS GCC under an old Borland Turbo-C look-alike
called RHIDE), the Microsoft driver development kit, hand-tweaked files,
etc., etc.

And *eventually* I'd like to get some of this stuff moved into a more
coherent format, and some of it moved into libraries (as it should be now),
and just generally cleaned up.  But that's not going to happen overnight,
and *right now* I've GOT to get a single coherent build system in place
before I go insane.  I know for a fact that the underlying directory
structure is gonna change... so if I can insulate as much of that from
pieces of the build system as I can, then that'd make my life easier.

That is to say - we have a serial port "library".  It's not really a library
right now, but it should be.  It'd be nice if I only have to change files in
one place, instead of two...

But, I guess for now, "hard-wiring" relative pathnames in the top-level
makefile sounds like it's the way to go for the foreseeable time, so that's
the path to follow for now.

(I still think that my idea of changing the "working directory" on the
include is a clever way around it, though...!)

Thanks, Zachary, since you seem to have uncovered some other things that I'm
not sure I would have figured out.  I'd gotten as far as the child->parent
communications issues... I hadn't worked out the sibling thing yet!