death to -{I,L}/our/{include,lib}!

Greetings fellow ARKdudes!  Things continue to creep along
at ARK Central, even *with* Matt pub-crawling his way across
Ireland...

I have a two-parter for your cogitation and on which to
dispense Wisdom and Cleverness... This one's the "problem"
and the next is a possible "solution"...

In Sidai package-land, we tend to compile with something
like...

   gcc -I/our/include -L/our/lib ...

Now, what's that all about then, Ted?  Well, individual
packages (e.g. zlib and libpng) will have *deployed* into
/.-ark-deploy/zlib--1.1.3 and /.-ark-deploy/libpng--1.0.9;
so you have #include files parked in
/.-ark-deploy/{zlib--1.1.3,libpng--1.0.9}/include and
libraries in the lib equivalents.  (Generalize this to about
150 packages or so, please... :-)

If you *reveal* those packages into /our, all those #include
files will appear in /our/include, and the libs in /our/lib.
In short, those dirs are (automagically-maintained) *unions*
of the include/lib files you happen to have at any one time.

This is nice, convenient, manageable, and... WRONG (right??)

It's wrong because we blithely pick up dependencies between
packages (one uses another's includes/libs) and we end up
with no knowledge or record.  Can you delete that libpng
that you built three years ago? -- you don't have a clue.

So: we need *not* to reveal include files and libraries into
/our; and then we need to compile/link against the
*deployed* stuff; thus, something like...

   gcc -I/.-ark-deploy/zlib--1.1.3/include \
       -I/.-ark-deploy/libpng--1.0.9/include \
       -L/.-ark-deploy/zlib--1.1.3/lib \
       -L/.-ark-deploy/libpng--1.0.9/lib ...

Now the dependencies are there in black-and-white in your
ARK bits...  (We can do this now and ugly-ly w/ current ARK
engine; next message will muse upon a tidier way to do it...)

Any thoughts or warnings?

Will