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
