[quake2] revamped build system

[Brendan Burns]

Hmm,
I think that this is because there are a large number of static data 
variables compiled into the object files and they don't get exported as 
part of the static library.  But I'm definitely not sure.

I think a first step in cleaning the build system would be to split up 
the Makefile and add in suffix rules.  I'm not sure there's a real good 
reason for building static libraries which are then only used to link a 
single executable.

Obviously, I'd be eager to see any improvements to the build system.

--brendan

On Sep 18, 2004, at 2:40 PM, tom fogal wrote:

> Hey all, I was trying to redo the build system in a (at least what I
> feel to be) better way, and I just can't get things to link correctly.
> I was hoping someone here has more quake2 or unix lore and could help
> me out.
>
> sdlquake2 builds with a line like the following:
>
> gcc -Wall -pipe -Dstricmp=strcasecmp -DQMAX -g 
> -DLINUX_VERSION='"3.21+rCVS Debug"' -o debugi386/sdlquake2 
> debugi386/client/cl_cin.o debugi386/client/cl_ents.o 
> debugi386/client/cl_fx.o debugi386/client/cl_input.o 
> debugi386/client/cl_inv.o debugi386/client/cl_main.o 
> debugi386/client/cl_parse.o debugi386/client/cl_pred.o 
> debugi386/client/cl_tent.o debugi386/client/cl_scrn.o 
> debugi386/client/cl_view.o debugi386/client/cl_newfx.o 
> debugi386/client/console.o debugi386/client/keys.o 
> debugi386/client/menu.o debugi386/client/snd_dma.o 
> debugi386/client/snd_mem.o debugi386/client/snd_mix.o 
> debugi386/client/qmenu.o debugi386/client/m_flash.o 
> debugi386/client/cmd.o debugi386/client/cmodel.o 
> debugi386/client/common.o debugi386/client/crc.o 
> debugi386/client/cvar.o debugi386/client/files.o 
> debugi386/client/md4.o debugi386/client/net_chan.o 
> debugi386/client/sv_ccmds.o debugi386/client/sv_ents.o 
> debugi386/client/sv_game.o debugi386/client/sv_init.o 
> debugi386/client/sv_main.o debugi386/client/s!
>  v_send.o debugi386/client/sv_user.o debugi386/client/sv_world.o 
> debugi386/client/q_shlinux.o debugi386/client/vid_menu.o 
> debugi386/client/vid_so.o debugi386/client/sys_linux.o 
> debugi386/client/glob.o debugi386/client/net_udp.o 
> debugi386/client/q_shared.o debugi386/client/pmove.o 
> debugi386/client/cd_sdl.o debugi386/client/snd_sdl.o 
> debugi386/client/snd_mixa.o -lm -ldl -L/usr/lib -Wl,-rpath,/usr/lib 
> -lSDL -lpthread
>
> (sorry, you might have to turn line wrapping on for that - to
> summarize, 'gcc', some CFLAGS, a bunch of object files from a mix
> of client/, server/, and linux/, and '-lm -ldl -
> L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread')
>
> I'm trying to make each directory into its own module of sorts,
> archived into a static library and then linked in when appropriate.
> I've pruned the archives so they only have the objects specified in the
> above commandline, but when I used a line such as:
>
> gcc -g -Wall -pipe -DQMAX -DLINUX_VERSION="\"3.21+\"" -Lclient/  \
> -Llinux/ -Lqcommon/ -Lserver/ -llinux -lclient -lserver -lqcommon -lm \
> -ldl -Wl,-rpath,/usr/lib -lSDL -lpthread
>
> I get a lot of undefined references to VectorMA and some other vector
> functions or globals. I even tried linking in the 'game' modules shared
> object (aka "gamei386.so"), which got rid of a lot of undefined
> references but still leaves me with a lot of undefined references to
> 'NET_'* and 'CDAudio_'*.
>
> Any ideas? BTW, my platform is linux if that matters much.
>
> As an aside, the motivation for this is ease of new additions to the
> engine. I am (was...) trying to add OpenGL-based dynamic lighting
> (instead of multi-texturing lightmaps) and wanted to add a new file to
> the build system, but it was not entirely intuitive.
> As I've been doing this I noticed a lot of awkwardness in the engine,
> like using 'extern <function_prototype>' instead of having header
> files, which seems unsafe to me. So now I'm more interested in making
> the build system catch stupidities as early as possible in the
> compile/link/run stages. I don't know if these changes/additions would
> be interesting to others, as I'm being kind of lax in keeping 
> non-q2max,
> software rendering, etc. working. If theres enough interest though, I
> could be convinced in being more diligent in making sure those work.
>
> Whew, that was long. Thanks for reading this far =)
>
> -tom
>