ASSS Questions - 1.4.0 Makefiles Dr Brain - Tue Jul 12, 2005 10:11 pm Post subject: 1.4.0 Makefiles
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?
50% Packetloss - Wed Jul 13, 2005 12:50 am Post subject:
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
Solo Ace - Wed Jul 13, 2005 1:22 am Post subject:
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
<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 - Wed Jul 13, 2005 5:05 am Post subject:
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:
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 - Wed Jul 13, 2005 5:14 am Post subject:
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 - Wed Jul 13, 2005 5:56 pm Post subject:
Heh, okay, thanks.
I'll try when I get back home.
Grelminar - Wed Jul 20, 2005 5:05 am Post subject:
By the way, this patch to src/Makefile will add the convenience aliases I mentioned.
