Server Help

[Dr Brain]

Ok, how the heck do the 1.4.0 .mk files work? I had everything set up beautifully on 1.3.6, but I don't know how to set them up for the new arrangement.

Any hints?
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[50% Packetloss]

For the windows built this is how I worked it.

In the windeps folder, fill the mysqlinc and pythoninc with the necessary files (found in your install directories for those 2 programs).
You will need to place python.exe in the windep folder aswell.
Then fill out the system.mk file with the correct info.
At the top of os.mk, the script was making dev-c++ spit out errors, so I shut it up by just commenting the small script and just telling it which compiler im using.
SYS_NAME := MINGW-dev-c++

Then it compiled fine <3
_________________
Current Terror Alert Level

[Solo Ace]

That's not going to work for what Brain wants, though, Linux.

I just have a few questions, because I was wondering the same.
Please don't kick me, the last version I used was 1.1.7.

What do you specify in the .mk files?
In grel's versions of the makefiles I see stuff like

Code: Show/Hide <binary name>_mods = <modules in the binary> <binary name>_libs = <libraries used by modules> $(eval $(call dl_template, <binary name>))

And some other things.
I don't know how this exactly works, but the dl_template in the .mk files calls the linking function "dl_template" in the Makefile?
What should exactly be in the .mk files?

What should be passed to make? How do I tell make to compile all modules, or just one single module?
I guess you could do something like putting a custommod/custommod.c and custommod/custommod.mk in the src dir and type make custommod/custommod, but I'm sure that's not the way to do it.

What is the .stamp for?

I didn't follow the project at all since I stopped, but heh, spending some time on finding the right way through this makefile jungle didn't do much good.

[Grelminar]

Yeah, sorry I didn't document any of this yet. Basically, use turf.mk as an example. Here's some guidelines snipped from an icq conversation that should help get you started:

- make a directory within src for a related set of modules.
- in that directory, put all your source, and one .mk file.
- use one .c file for each module, and have the name of the .c file match the name of the module.
- create a .mk file in the directory. use turf.mk as an example. the basic structure is: to put modules foo1, foo2, and foo3, defined in foo1.c, foo2.c, and foo3.c, into foos.so, do this:

# foos.mk
foos_mods = foo1 foo2 foo3
$(eval $(call dl_template,foos))

if you need special flags for the link command (to link against zlib, for example), set foos_libs to those flags.
- run "make deps" from the src directory to pick up the new .mk file, then run "make", and your module should be compiled, linked, and installed into the bin directory.

the new stuff puts output files, including .o and .so files, in a separate build directory, so they don't clutter up your source directory. by default, it's "../build", taken relative to "src". so to compile only a specific module, do "make ../build/foos.so". in the next version, I'll set it up so that "make foos" works also.

[Grelminar]

The stamp files are used because you can't make make depend on a directory. You have to set up a dependency on a file within the directory, and have the rule for creating the file create the directory. It's a common makefile trick.

[Solo Ace]

Heh, okay, thanks.
I'll try when I get back home.

[Grelminar]

By the way, this patch to src/Makefile will add the convenience aliases I mentioned.