2002.10.28 ~09  Thoughts on Blender win32 build, and q3asm "static" keyword

+ Blender win32

Blender is a cross-platform app, so consistency dictates the build process
should remain cross-platform.  The problem is that the primary compiler
used in win32 is Microsoft Visual... um... Studio? C++?  Whatever.
(Whether this can be considered "the system's C compiler" is a topic of
another rant).  The point stands that MSVC isn't very make(1)-unfriendly,
is very non-standard.  The problem is that automake as-is does not work
well with MSVC as the C(++) compiler.

One solution is to attempt to conjure up the necessary MSVC files based on
the automake files.  This method seems doable -- the tree structure of the
source is patterned enough to establish a build path even without the
automake files.  The problem with this attempt is, again, non-standardism.
I can't grok the formats of the MSVC files (the ones packaged with the
Blender source tree).  Or maybe I don't want to... but they seem just plain
weird.  Primarily on issues such as whether those header lines are
critical, the sensitivity on whitespaces (valid chars and amounts), and wtf
are the comment delimiters.  Oh yeah, and those crazy-ass backslash for
path separator.

Wonder if there's a grammar describing these .dsp (.dsw?) files.

+ q3asm

I have many reasons for wanting to split q3asm into two distinct programs,
q3as and q3ld.  One is to assist the migration of q3vm compilation into GCC
later on (WAAAAAAY later on).  Another is to allow use of library (.a)
files in Q3VM linking -- this helps cut down on reaching across
directories, as is currently done in cgame/ for obtaining bg_* (both games)
source files.  Related is testing my libc reimplementation, to avoid
repeated recompilation and to test standalone worthiness (i.e. not
intimately linked to my mod).  An offshoot to that is properly handling the
C keyword "static" (libc has stuff that really should be private).

I already started on a hack for "static" support, using the source filename
as a "tag" to symbol names, to make symbols unique to a particular source
file.  This establishes private namespaces per file.  The sticky part with
this method is trying to get globals to be globals.  At some point the
filename-"tag" portion needs to be stripped (simple), and somehow resolve
to the unique still-tagged symbol (a little hairy), while ensuring no
conflicts (some more hair).  The key to the breakthrough lies in the
assembler directives "import" and "export".  The hard part is trying to
come up with the proper data structures to express this method of scoping.
I think I need to work out some more of this on paper.

I really want to shift q3asm's symbol table to a tree, for many reasons.
For one, trees would boost the speed some more (although the need is
arguable, as some people are getting reported time-elapsed of 0 seconds).
Second, the data structure and methods for trees are much neater than those
for a chain-and-bucket hash table.  And finally, trees are just cool.  For
speed reasons, the tree would need to be weight-balanced somehow.  I would
like to just link to a tree library of some kind, but that would be an
extra burden on whomever wants to use the tree'd q3asm.  So my options are
either to rip tree code and stuff 'em into q3asm, or dig through my CS
books again looking at the tree implementations.  I understand the basic
concept of R-B tree, that the markings help keep the balance... but I just
get lost in all those rotations. :(