Need help deciphering posix.mak

[H. S. Teoh via Digitalmars-d]

On Thu, Nov 27, 2014 at 11:17:34PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> Okay, so I'm prepping up a SCons build of Phobos.

Hooray!


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

Very nice!


> Some make targets are trivial to translate (ddocs, zips etc.) but
> unittest runner and SO/PIC build flags is an arcane mess.

Well, building SO/PIC itself 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.

I've tried looking into that before... unfortunately I didn't have the
patience to figure it out either.


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

Wait, what? What's the point of running -deps and sed/sort/whatever if
we don't actually care about it in the first place?


> 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

Well, the current makefile *does* assume druntime is in ../druntime (it
does strange things if that's not true, and that's not just for the
unittester), so what can you say...


> 6. Run it passing a specific module to unittest:
> https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L355

Whoa, really?! Why can't we do per-module test drivers?


> 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).

I think you have to do a second pass, i.e., recompile the entire Phobos
with -pic, -lib, etc., to get the .so.

Also, don't forget the 'html' target that builds the docs. Currently
it's quite broken (e.g., std.windows.charset is not being built, so on
dlang.org this is a dangling hyperlink). But basically, you just compile
the entire Phobos all over again with -D, -Dd, etc., and include the
.ddoc files on each command-line. Shouldn't be too hard to do in SCons,
though.

My personal advice is to run this as a *separate* step (`dmd -o- -D
-Dd...`), and don't try to "optimize" by combining ddoc generation with
actual compilation, since that will make your SCons dependency tree
*really* hairy, and you might end up with subtle bugs if you don't
insert the correct Depends() lines or if you don't specify *all* files
output by dmd. Plus, for the doc-generation build, you want to generate
docs for *all* source files, even those not intended for the host
platform, so your list of input files will be different from the actual
build. Better keep the two separate.


> 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.
[...]

Sounds like an excellent idea!


T

-- 
By understanding a machine-oriented language, the programmer will tend
to use a much more efficient method; it is much closer to reality. -- D.
Knuth