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

Will Partain <[email protected]> writes:

> 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,

don't you also have a problem with runtime linking?  If you are
concerned about compile time linking against a specific version how
are you going to ensure that the run-time link editor is picking up
the correct library at run time?

If you do gcc -L/.-ark-deploy/zlib--1.1.3/lib you would also have to
do LD_LIBRARY_PATH=/.-ark-deploy/zlib--1.1.3/lib, right? Or are you
fine with the versioning used by the run-time link editor,
ie. major.minor number for libraries in /our/lib ?

Rolf