Questions about compile options (ioq3 on Solaris).

[Tim Angus]

On Fri, 28 Oct 2005 15:15:08 +0200 (CEST) vincent at cojot.name wrote:
> I'm working on making a Solaris port of ioq3 and I have many
> questions...

I think ankon was/is working on a Solaris port. I'm not sure what stage
he got to, but perhaps you two should talk and avoid duplication of
effort :).

> Is there some kind of documentation on the use of:
> -DHAVE_VM_NATIVE
> -DHAVE_VM_COMPILED
> -DDLL_ONLY
> 
> I have never produced a q3 mod so that may be why I don't know this
> stuff  but that would help me if someone would tell me what are these
> things and  especially what combination would be recommended when
> porting to a new  platform and retaining decent functionnality...

Q3 mods have three distinct modes of execution. They can be compiled to
native shared libs (i.e. .so/.dll) ala Q2 or to platform independant
bytecode. The libs can only be executed one way, obviously. The bytecode
can be interpreted, or JIT compiled to the native instruction set. Which
of these options is used is specified by the cvars vm_game, vm_cgame and
vm_ui for each module respectively. A value of 0 means to use native
libs, 1 to interpret bytecode and 2 to JIT compile bytecode.

HAVE_VM_NATIVE specifies that the platform is capable of using native
libs.
HAVE_VM_COMPILED specifies that the platform has a bytecode JIT
compiler.
There is no define HAVE_VM_INTERPRETED since in theory the interpreter
should work everywhere (though it is the slowest option).

DLL_ONLY comes from before ioq3 as a means of disabling any bytecode
mechanisms. I'm not convinced this is really useful anymore, perhaps it
should be removed.

As an aside, I've been thinking for a while that HAVE_VM_* should really
live in a header rather than defined by the build system. The main
reason for this is that currently only the linux and mingw builds have
these defined since nobody has added the relevant bits to the build
systems on OS X and VC. In other words these builds can ONLY use
interpreted bytecode at the moment. Obviously it's trivial to fix the
build systems, but from a maintenance point of view it makes more sense
to save us the bother (now and in future) and put the defines in a
header. Also, with the exception of x86_64 for now, I don't really see
the HAVE_VM_* defines as being something that should be end user
optional, especially since the runtime behaviour can be chosen using the
vm_* cvars. Opinions?