gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Compiling with makefile using SGADE

#115074 - HoodedNinjaMan - Fri Jan 12, 2007 8:16 pm

I hope I'm not still considered a novice to programming for this, but I'm having problems using makefile for the SGADE library, using the Devkit Advance compiler. I've read and re-read a lot of material and am fairly certain that I have all my files in the right places, but I can't seem to get rid of several errors when I go to make my .gba file.

(I grabbed the makefile file straight from the SGADE website and modified it accordingly)

The errors it returns are as follows:

error makefile 120: redefinition of target '/,'
error makefile 127: too many rules for target ')'
error makefile 129: no match found for wildcard '(/*.d),)'
error makefile 129: command syntax error
error makefile 130: command syntax error
error makefile 131: command syntax error

If anyone can help me resolve these errors, I would greatly appreciate it.

PS: If I put this in the wrong section, help me move it or something. Everyone's new somewhere at some point in time, you know?

Edit: here's the makefile that I'm using
Code:
# -----------------------------------------------------------------------------
#
# This file contains the build instructions for the SGADE library. In order to
# use it you need to change the CMP_DIR to the location of the GBA toolchain on
# your computer.
#
# $Id: Makefile,v 1.7 2005/07/10 05:53:52 mprice Exp $
#
# -----------------------------------------------------------------------------

PROJECT = PearlHarbor

# -----------------------------------------------------------------------------
# Base directory for the GBA compiler. Replace this with wherever
# you have put it.
# -----------------------------------------------------------------------------
CMP_DIR = c:/devkitadv

# -----------------------------------------------------------------------------
# Base directory for the SGADE. Replace this with wherever you have put the
# SGADE source on your computer.
# -----------------------------------------------------------------------------
SGADE_DIR = ..

# -----------------------------------------------------------------------------
# MVB2 include directory. This is ignored if you don't use MBV2 specific stuff
# like console debugging in your code.
# -----------------------------------------------------------------------------
MBV2_INC_DIR = /usr/local/gba/mb/include

# -----------------------------------------------------------------------------
# Source, object, and library directories.
# -----------------------------------------------------------------------------
INCLUDE_DIR      = $(SGADE_DIR)/include
SRC_DIR         = $(SGADE_DIR)/source
O_DIR         = $(SGADE_DIR)/build/intermediate
LIB_DIR         = $(SGADE_DIR)/lib

# -----------------------------------------------------------------------------
# The compiler flags.
# -----------------------------------------------------------------------------
GCC_FLAGS = -I $(INCLUDE_DIR) -I $(MBV2_INC_DIR) -g \
   -Wall -MMD -fverbose-asm -mthumb -mthumb-interwork
GCC_ARM_FLAGS = -I $(INCLUDE_DIR) -I $(MBV2_INC_DIR) -g \
   -Wall -MMD -fverbose-asm -marm -mthumb-interwork
GCC_S_FLAGS = -I $(INCLUDE_DIR) -I $(MBV2_INC_DIR) -g \
   -Wall -fverbose-asm -marm -mthumb-interwork

# -----------------------------------------------------------------------------
# All the object files to be built.
# -----------------------------------------------------------------------------
O_FILES_FROM_C = \
   SoBkg.o \
   SoBkgCreditScroll.o \
   SoBkgConsole.o \
   SoBkgFont.o \
   SoBkgManager.o \
   SoBkgMap.o \
   SoBkgMemManager.o \
   SoCamera.o \
   SoDMA.o \
   SoDebug.o \
   SoDebugPrintf.o \
   SoDisplay.o \
   SoEffects.o \
   SoFlashMem.o \
   SoFont.o \
   SoImage.o \
   SoIntManager.o \
   SoKeys.o \
   SoMath.o \
   SoMatrix.o \
   SoMemManager.o \
   SoMesh.o \
   SoMeshCube.o \
   SoMode4PolygonRasterizer.o \
   SoMode4Renderer.o \
   SoMultiPlayer.o \
   SoPalette.o \
   SoPolygon.o \
   SoSound.o \
   SoSprite.o \
   SoSpriteAnimation.o \
   SoSpriteManager.o \
   SoSpriteMemManager.o \
   SoSystem.o \
   SoTables.o \
   SoTimer.o \
   SoTransform.o \
   SoVector.o \
   SoWindow.o \
   SoTileSet.o

O_FILES_FROM_S = \
   SoIntManagerIntHandler.o \
   SoMathDivide.o \
   SoMode4RendererClear.o \
   SoTileSetCopyFromLinearBuffer.o \
   SoMode4PolygonRasterizerSolidTriangle.o

//Redefinition of target '/,' occurs here
O_FILES_FROM_S_FULL_PATH = $(addprefix $(O_DIR)/, $(O_FILES_FROM_S) )
O_FILES_FROM_C_FULL_PATH = $(addprefix $(O_DIR)/, $(O_FILES_FROM_C) )

O_FILES_FULL_PATH = $(O_FILES_FROM_S_FULL_PATH) $(O_FILES_FROM_C_FULL_PATH)

# -----------------------------------------------------------------------------
# Build targets.
# -----------------------------------------------------------------------------
all: $(LIB_DIR)/$(PROJECT).a

$(LIB_DIR)/$(PROJECT).a: $(O_FILES_FULL_PATH)
   @echo Archiving object files to library $@
   @$(CMP_DIR)/bin/ar -rcs $@ $(O_FILES_FULL_PATH)

$(O_FILES_FROM_C_FULL_PATH): $(O_DIR)/%.o: $(SRC_DIR)/%.c
   @echo Making $@
   @$(CMP_DIR)/bin/gcc -c $< -o $@ $(GCC_FLAGS)

$(O_FILES_FROM_S_FULL_PATH): $(O_DIR)/%.o: $(SRC_DIR)/%.S
   @echo Making $@
   @$(CMP_DIR)/bin/gcc -c $< -o $@ $(GCC_S_FLAGS)

# -----------------------------------------------------------------------------
# Dependencies. They should be included before clean is defined (since it
# removes them) and after GCC has run (since it creates them).
# -----------------------------------------------------------------------------
//No match for wildcard occurrs here
DEPS = $(wildcard $(O_DIR)/*.d)
ifneq ($(DEPS),)
   include $(DEPS)
endif

.PHONY: clean
clean:
   @echo Removing object and dependency files
   @$(RM) $(O_FILES_FULL_PATH) $(DEPS)

rebuild: clean all

_________________
Light travels faster than sound. That is why some people appear bright until you hear them speak.

Last edited by HoodedNinjaMan on Fri Jan 12, 2007 9:12 pm; edited 1 time in total

#115076 - Miked0801 - Fri Jan 12, 2007 8:41 pm

Can you post the makefile or at least the area around the errors for us?

#115079 - HoodedNinjaMan - Fri Jan 12, 2007 9:14 pm

Thanks for replying, unfortunately I have to leave the internet until tomorrow and won't be able to reply again until that time.
_________________
Light travels faster than sound. That is why some people appear bright until you hear them speak.

#115092 - Cearn - Fri Jan 12, 2007 11:27 pm

Not 100% sure this is it, but I remember having problems with it in the past ...

HoodedNinjaMan wrote:
Code:
SGADE_DIR = ..

There are two flavours of variables, ones made with ':=' and ones with '='. The former works more like a normal variable definition, but the latter work more like a macro: direct text substitution. In this case, you have a space after the two dots, which will also go into INCLUDE_DIR and the others. Getting rid of the space or use := could help.

More whitespace fun:
make requires tabs before commands and not spaces.
The line-break character '\' but come directly before newline, no space or tab allowed there either

#119987 - werty - Wed Feb 28, 2007 2:34 am

error makefile 129: no match found for wildcard '(/*.d),)'
error makefile 129: command syntax error
error makefile 130: command syntax error
error makefile 131: command syntax error

If anyone can help me resolve these errors, I would greatly appreciate it.






I found the problem . The s/w was not designed to
help , it was designed to teach you arbitrary 'syntax" .

Good s/w has NO sintax . It knows what you need ,
and does it .

Why do you think this is the best way to do this !!
Why dont we "shop" around , and buy the easy s/w ?

Partial answer is , we are "hooked" on the applications.
we think the apps are too valueable to just drop and
start over .
But that depends on how they were written .

If you buy a better , in place , instant compiler
that has no make files . maybe recretaing all those
old apps maybe a 2 day job . because the new compiler
wont have sintax , nor delays , nor promises ...
In place means it creates code instantly , so one
can test it instantly .
Good s/w has a library , but that library has a library !
It means you create your app from lib routines that
in turn call other lib routines .
They are highly structured , so you can see what they
do . It makes debugging easy , because you can
test the hi level , or simgle step the mid level ,
or SS each low level , instantly , no interpreting ,
no compiling , nothing ...
It has no sintax , it has no text , no English ,
no definitions to "learn" .

Less is good .

If 10,000 programmers , all over the world
wrote their own version ,
all versions would look same !

So why struggle , do it the easy way .
You can create this new HLL , by yourself .

The mistakes you will make , are to want to
create the whole assembler . DONT , just create
the simple op codes and then move on to the
next level , and create Primatives that take all
the work and details out of "assembling" code .
No asm directives , no "label" rules , no stupid
.define VOID EQU
No tricky positional stuff .
Theres NO TEXT ! You must create tiny ICONs
that make an instand impression in all programmers
minds ... Like MOV will be a image of a truck .
Branch must be a traffic sign "FORK" .

The rules are NO TEXT , NO unintuitive symbols .
Registers are , obviously a row of houses .
there are 32 houses on a cul-de-sac .
There are only houses on one side of the street .

How can you forget that !
Try memorizing CP15 !! Impossible !

But now make a huge complicated image
in ur mind of all the registers in CP15 and
their functions , but with images !

You will be a wizard in 20 minutes , as
you accurately recall those functions .

This is because the left brain has lots of
excuses why it can't remember text ,
but Right side uses images , thus can
easily form an accurate
image of the insides of a computer .

Try it .....its 100 times faster .

#119989 - keldon - Wed Feb 28, 2007 2:48 am

Permission to say STFU ^_^ Just cut to the damn chase, show us what the hell you are trying to promote, it's just getting on my nerves. It's like torturing a victim before killing them; just show us the damn spam. It worked, I want to see the spam. I can't stand this text any more!!!

#120018 - chishm - Wed Feb 28, 2007 11:49 am

I must say it is interesting spam. However, it promotes structure:
Quote:
They are highly structured , so you can see what they
do . It makes debugging easy , because you can
test the hi level , or simgle step the mid level ,
or SS each low level , instantly , no interpreting ,
no compiling , nothing ...

But then it goes on to say don't use structured text, use images. Images are slow and cumbersome. A GUI is harder to use for repetitive tasks than a scriptable text interpreter. Programming is not just point and click.

Now, if you aren't spam, explain why you believe grahphical-symbol based programming is better.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#120022 - keldon - Wed Feb 28, 2007 12:21 pm

He has (somewhere) and does make some sense, but the idea is useless if not researched and no outcome is achieved. No text at all would be shooting yourself in the foot but you can create a lot of structure graphically that is easy to understand to an extent however it does require labels.

#120027 - chishm - Wed Feb 28, 2007 1:00 pm

So it's something like programming with Lego Mindstorms then.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

#120031 - keldon - Wed Feb 28, 2007 1:16 pm

chishm wrote:
So it's something like programming with Lego Mindstorms then.


Cool!