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
