Need help deciphering posix.mak

[Dmitry Olshansky via Digitalmars-d]

Okay, so I'm prepping up a SCons build of Phobos. It comes along rather 
nicely, I've replicated most of posix.mak paraphernalia in ~150 LOC that 
does work for both Windows and Linux, the rest of POSIX to follow shortly.

Some make targets are trivial to translate (ddocs, zips etc.) but 
unittest runner and SO/PIC build flags is an arcane mess. So I'm asking 
if anybody know what's the heck it tries to do and can just tell me to 
save the time on reverse-enginering.

What I know(?) so far:
1. First we build library in one go - trivial to reproduce.
2. Then we compile each unittest with -c and -deps to dump actual 
dependencies.
3. Then we run a bunch of sed/sort/uniq to extract module names from 
verbose output of compiler (red flag IMHO, but anyway).
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L325
4. We promptly ignore these files afterwards...
5. We build a unittester from Druntime (pulling sources out of tree - 
omg) with ALL of object files:
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L334
6. Run it passing a specific module to unittest:
https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355

I hope I got it right. And I'm not entirely sure where SO/DLL fits 
(except for setting the PIC flag which is quite straight-forward).

My hopes are that once I get over these obstacle and replicate whatever 
we wanted here in the first, we could get down to 2 files for all of our 
platform builds:
1. SConstruct - setup environment, detect OS, fiddle with parameters and 
in general defines "how" to build stuff (estimate: 160-180 LOCs)
2. SConscript - a laconic file showing what to build, doing so in simple 
cross platform, with plain *.d globs. (estimate: about 60-70 LOCs)

That means in general that SConstruct is changed only for new 
platform/compiler and SConscript only when source/targets structure 
radically changes.


-- 
Dmitry Olshansky