#114 - regularkid - Fri Jan 03, 2003 5:17 am
Quick GBA makefile question. Instead of doing this:
main.o : main.c common.h blah.h junk.h, etc
I heard that you could do this:
DEPEND= makedepend $(CFLAGS)
etc...
# what are the source dependencies
depend: main.c
$(DEPEND) main.c
etc....
# DO NOT DELETE THIS LINE -- ....
main.o: /usr/include/stdio.h
In order to find out what header files are included into a source file. Is there a way of doing this in gcc for GBA? Also, how does this work? This is where I got that info from:
http://vertigo.hsrl.rutgers.edu/ug/make_help.html
at the bottom of the page.
Thanks!
_________________
- RegularKid
#124 - Touchstone - Fri Jan 03, 2003 6:33 pm
Funny you should ask. I've just managed to automatically generate dependencies in the makefile.
I've added a new target in my makefile called 'depend' and it looks something like this:
Code: |
depend :
$(GCC_DIR)/gcc -c -M $(CFILES) > $(CDEPEND) |
GCC_DIR is just the path to my gcc executable
CFILES is a list of all the C files in the project (just listed as 'main.c input.c sound.c' etc..)
CDEPEND is just the filename of my dependency file, in my case 'cdepend'
It's the switch '-M' that makes GCC generate dependencies to stdout which is piped to the file cdepend. When this is done you have to include the dependency file in your makefile. I've put the include statemend in the end of my makefile like so:
To generate the dependency file just ask for the 'depend' target when making like so from your command-line: make depend
As a supplementary, this is what my entire dependency target looks like (running on Mac OS X):
Code: |
depend :
@echo Generating dependencies
$(SILENT)$(SHELL) -ec '$(GCC_DIR)/gcc -c -M $(CFILES) \
| sed '\''s/^[a-z]/$(subst /,\/,$(OBJDIR))&/g'\'' > $(CDEPEND)' |
First I generate the dependencies to stdout which is piped to the program sed's stdin. Sed process the text-stream, adding the text $(OBJDIR) before all dependency targets then sending the processed text to it's stdout which is piped to the file $(CDEPEND). This is because I need the dependency targets to look like build/obj/main.o: src/main.c src/main.h src/input.h instead of main.o: src/main.c src/main.h src/input.h. Notice the added directory in the target name. This is because I don't want the object files laying around the same directory as the source-files.
#158 - regularkid - Sat Jan 04, 2003 1:34 am
Thanks! But I'm still a tad bit confused, could you post your entire makefile? Basically, I want mine to work where I give it all my .c files and then it only builds the ones that need to be build (ie. the ones where an included header file has changed or the .c file itself has changed). That is where the dependency comes in. It would be really tedious to have to update the makefile with each .h that an .o file is dependent on. Example: If I have this:
main.o : main.c common.h junk.h blah.h
gcc -c main.c
and, say I add:
#include "anotherInclude.h"
to main.c . I don't want to have to update my makefile to look like this:
main.o : main.c common.h junk.h blah.h anotherInclude.h
gcc -c main.c
I want all my makefile lines to only have the .c file that an .o file is dependent on and then have it automatically generate what .h files the .o file is also dependent on. Is that what yours does? Thanks again.
_________________
- RegularKid
#177 - Touchstone - Sat Jan 04, 2003 1:15 pm
Uhm, my makefile could be a bit confusing if you are not used to them. Anyways, what my makefile does is generate a list of dependencies for all object files and then I have a 'generic' (I think it's called generic) .o from .c target that defines how each C file should be compiled. That way I just have my list of C files that should be compiled and I have the .O files dependencies. Argh, I'm so confused from a cold I can't explain it properly. Here is my makefile:
Code: |
GCC_DIR = /usr/local/gbasdk/arm-agb-elf/bin
CC = $(GCC_DIR)/gcc
BLDDIR = release/
SRCDIR = src/
OBJDIR = $(BLDDIR)obj/
SILENT = @
CFILES = src/main.c
CFILES += src/sys/input.c
CFILES += src/sys/file.c
CFILES += src/game/gamecontext.c
CFILES += src/game/gcIntro.c
CFILES += src/sys/mt.c
#CFILES += src/game/anima.c
CFILES += src/sys/Math.c
CFILES += src/sys/Graphics.c
CFILES += src/sys/Tweety.c
#CFILES += src/game/gcExplore.c
#CFILES += src/game/gcUnarmedFight.c
#CFILES += src/data/Animations.c
# src/sys/debug.c
# src/sys/dbgFont.c
SFILES = src/crt0.s src/data/libfile.s
OFILES = $(subst $(SRCDIR),$(OBJDIR),$(SFILES:.s=.o)) \
$(subst $(SRCDIR),$(OBJDIR),$(CFILES:.c=.o))
BINFILE = $(BLDDIR)ProjectB.bin
ELFFILE = $(BLDDIR)ProjectB.elf
MAPFILE = $(BLDDIR)ProjectB.map
CDEPEND = cdepend
CFLAGS = -I -mthumb -mthumb-interwork -g -Wall -fverbose-asm
SFLAGS = -mthumb-interwork
LFLAGS = -Tbss 0x03000000 -Tdata 0x08000000 -Ttext 0x08000000
$(BINFILE) : depend makefile $(ELFFILE)
@echo Stripping ELF information
$(SILENT)$(GCC_DIR)/objcopy -v -O binary $(ELFFILE) $(BINFILE)
$(ELFFILE) : $(OFILES) makefile
@echo Linking $@
@-mkdir -p $(dir $@)
$(SILENT)$(GCC_DIR)/ld -o $(ELFFILE) -Map $(MAPFILE) $(LFLAGS) $(OFILES)
$(OBJDIR)%.o : $(SRCDIR)%.c makefile
@echo Compiling file $<
@-mkdir -p $(dir $@)
$(SILENT)$(GCC_DIR)/gcc -c -o $@ $(CFLAGS) $<
$(OBJDIR)%.o : $(SRCDIR)%.s
@echo Assembling file $<
@-mkdir -p $(dir $@)
$(SILENT)$(GCC_DIR)/as -o $@ $(SFLAGS) $<
clean :
@echo Removing intermediate files
-$(SILENT)rm $(BINFILE) $(ELFFILE) $(MAPFILE) $(OFILES) $(CDEPEND)
depend :
@echo Generating dependencies
$(SILENT)$(SHELL) -ec '$(GCC_DIR)/gcc -c -M $(CFILES) \
| sed '\''s/^[a-z]/$(subst /,\/,$(OBJDIR))&/g'\'' > $(CDEPEND)'
$(CDEPEND) : depend
test :
all : clean depend $(BINFILE)
release : $(BINFILE)
debug :
@echo $(CFLAGS)
include $(CDEPEND) |
What you are interested in is the 'generic' .O target. A cleaner target would look like this:
Code: |
%.o : %.c
gcc -c -o $@ $(CFLAGS) $< |
That way, if you have an .o target that is dependant on a .c file (instead of a .s file) the target %.o : %.c is what's executed. With this generic target in place you just write down your .o dependencies to look like this:
Code: |
main.o : main.c .. all dependencies goes here |
Incidentally this is the format you get when you let gcc automatically generate dependencies with this command line:
Hmm, a simple makefile that uses this automatic dependency thingie without getting to complex could look like this:
Code: |
SFILES = crt0.s
CFILES = main.c
OFILES = $(SFILES:.s=.o) $(CFILES:.c=.o)
CFLAGS = -I -mthumb -mthumb-interwork -g -Wall -fverbose-asm
SFLAGS = -mthumb-interwork
LFLAGS = -Tbss 0x03000000 -Tdata 0x08000000 -Ttext 0x08000000
test.bin : test.elf
objcopy -v -O binary test.elf test.bin
test.elf : $(OFILES)
ld -o test.elf $(LFLAGS) $(OFILES)
%.o : %.c
gcc -c -o $@ $(CFLAGS) $<
%.o : %.s
as -o $@ $(SFLAGS) $<
depend :
gcc -c -M $(CFILES) > makedepend
include makedepend
|
I don't know if that makefile works because I just tossed it together but if it does work you use it by first doing 'make depend' to generate the file 'makedepend'. In this 'makedepend' all .o files that are generated from .c files are listed with dependencies. The just call 'make' again when you have the 'makedepend' file. You probably need to have a target for the .s files to.
Try out the gcc -c -M main.c and you will see that it generates dependencies for you. That, in combination with the generic .O from .C target is what you are interested in.
#271 - regularkid - Sun Jan 05, 2003 8:20 pm
Dude! You are awsome! Thank you soo much for explaining that all to me. I think I understand now. I've asked this question before but no one has given me a good answer until you! Thanks again.
_________________
- RegularKid
#283 - Touchstone - Sun Jan 05, 2003 10:41 pm
Cool.. Thanks!
#336 - KashinKoji - Mon Jan 06, 2003 5:32 pm
Hey touchstone I've been thinking of that same problem. Thanks for posting those makefile portions. Have you also put in BMP's or other graphics files into your dependencies, so they are converted with gfx2gba or another tool if they are updated between makes?
#365 - Touchstone - Mon Jan 06, 2003 9:41 pm
You're welcome Koji.
I don't convert data in my makefiles. There are two reasons why I decided against doing so.
1) Version control. I simply don't want new data to be linked into my executable without me explicitly asking for it. Say an artist is updating some sprite data and the new data is erroneous, you might think the problem is because of something in your code. In that case it's better to isolate the retreival of new data so you can verify that the new data works before going back to code.
2) Unified data access. I've written an data access interface which I'm using through all of my code which allows all kinds of data that is accessed via this interface to be compressed for instance. (ok, compression isn't supported yet but that's the idea anyways :)
I could use a makefile to convert my data and still comply with my notes above but I don't do that at the moment. I used to be developing on PC (Win32) but I've recently switched to Mac OS X so now I'll have to decide on how I should manage the conversion of all my data. There's actually quite much to take into considerations. :) For instance, should I get the source BMP file from my artist or should he do the conversion from BMP to plain BINARY and hand me the BINARY? Should I supply my artist with a testbed on which he can test his latest data without bothering me about it? Up until now I've converted all files by hand as the artist have had a new version done but I'm rethinking all of this as I have to recode all the tools anyway.
_________________
You can't beat our meat
#409 - KashinKoji - Tue Jan 07, 2003 3:43 pm
I see your point.
I was thinking I would implement my makefile to do the conversions because I see myself doing a lot of tweaking in that department. So far I just use the GIMP to do my sprite design, and I convert with command line gfx2gba.
I thought I would wind up rebuilding with new sprite data quite a lot to get the right" look". The further I go into this gba development (and video game development in general, I am rather new at) I realize that the right look I'm looking for is actually the right "feel", and is more dependant on the mathematical behavior of the sprite in motion, and I must humbly outsource the artwork to someone else.
I arranged with an artist friend of mine to do sprite design/animation and I am making a simple test program so that he can run his stuff on an emulator. He is not a programmer, so I thought a makefile with data dependancies would be good for that purpose, in the frame of a completely static test program with no updating going on except the sprite data.
Thanks for the input.
#436 - Ped - Tue Jan 07, 2003 6:30 pm
I posted some sort of "universal" makefile to GBA dev mailing list few months ago and I never get any response or comments, but it looks like you might be the right person to give it a look... I'm also doing gfx conversions in makefile .. mail me some "request" e-mail, I'll send it to you. (but basically most of the info is already written here, it may be worth just like another example)
_________________
-- Ped - ped at 7gods dot sk
there used to be times, when sex was safe and flying was dangerous...