Forum: Compiler & IDEs makefile funktioniert nur bei make all


von uze (Gast)


Angehängte Dateien:

Lesenswert?

Hallo

Ich programmiere gerade ein Spiel für die Uzebox und musste dafür das 
Makefile verändern, da ich neue Dateien zum Projekt hinzufügen musste. 
Sobald ich aber eine der hinzugefügten Dateien bearbeite, gibt avr-gcc 
seltsame Fehler aus, deren Ursprung ich nicht nachvollziehen kann:
1
avr-gcc.exe: error: c:avr-gcc-4.7.1-rc1-mingw32bin../lib/gcc/avr/4.7.1/../../../../avr/include/avr/io.h: No such file or directory
2
avr-gcc.exe: error: c:avr-gcc-4.7.1-rc1-mingw32bin../lib/gcc/avr/4.7.1/../../../../avr/include/avr/sfr_defs.h: No such file or directory
3
[...]

Folgende Zeilen habe ich im Makefile geändert/hinzugefügt:
1
### Source files and search directory
2
CSRC    = sd/pff.c sd/mmc.c
3
ASRC    = sd/xitoa.S sd/usi.S animation.S
4
5
[...]
6
7
## Objects that must be built in order to link)
8
OBJECTS = uzeboxVideoEngineCore.o uzeboxCore.o uzeboxSoundEngine.o uzeboxSoundEngineCore.o uzeboxVideoEngine.o $(GAME).o $(notdir $(CSRC:.c=.o)) $(notdir $(ASRC:.S=.o))
9
10
[...]
11
12
## Compile other asm files
13
$(notdir $(ASRC:.S=.o)): $(addprefix ../, $(ASRC))
14
  $(CC) $(INCLUDES) $(ASMFLAGS) -c  $+
15
16
## Compile other c files
17
$(notdir $(CSRC:.c=.o)): $(addprefix ../, $(CSRC))
18
  $(CC) $(INCLUDES) $(CFLAGS) -c  $+

Das Makefile befindet sich in einem Unterordner, daher wird das prefix 
../ hinzugefügt. Seltsam ist außerdem, dass es keine Fehler gibt wenn 
ich alles neukompiliere.
Mit Makefiles kenne ich mich leider nur sehr wenig nicht aus, vielleicht 
kann mir einer einen Tipp geben, was ich ich falsch gemacht habe.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

uze schrieb:
> Mit Makefiles kenne ich mich leider nur sehr wenig nicht aus

Dafür ist es mir aber unverständlich, warum du so verkorkste
GNUmakeismen benutzt wie:

$(notdir $(ASRC:.S=.o)): $(addprefix ../, $(ASRC))

VPATH und Standard-Bildevorschriften für Assembler- und C-Quelldateien
sollten da viel besser zu überschauen sein.

http://www.gnu.org/software/make/manual/html_node/General-Search.html

(Ja, VPATH ist auch ein GNUismus, aber m. E. viel einfacher zu
beherrschen als ein Wust von Funktionen.)

von uze (Gast)


Angehängte Dateien:

Lesenswert?

uze schrieb:
> Mit Makefiles kenne ich mich leider nur sehr wenig nicht aus

Sollte natürlich heißen, dass ich mich nur wenig auskenne...
Ich hab gesten ein paar Tutorials überflogen, in denen ich diese 
Funktionen gefunden habe.

VPATH macht die ganze Sache natürlich angenehmer - leider behebt es den 
Fehler nicht.

Ich habe vorher vergessen den Compileraufruf zu posten. An dem sieht man 
auch, dass es Fehler geben muss:
1
avr-gcc -I"../kernel" -mmcu=atmega644 -mmcu=atmega644 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=28636360UL -Os -fsigned-char -ffunction-sections  -MD -MP -MT xitoa.o -MF dep/xitoa.o.d  -DVIDEO_MODE=2 -DINTRO_LOGO=1 -DMIXER_CHAN4_TYPE=1 -DSCREEN_SECTIONS_COUNT=2 -DVRAM_TILES_V=32 -DMAX_RAM_SPRITES=12 -x assembler-with-cpp -Wa,-gdwarf2 -c  ../sd/xitoa.S ../sd/usi.S ../animation.S ../animation.S c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/io.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../
2
lib/gcc/avr/4.7.1/../../../../avr/include/avr/sfr_defs.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/iom644.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/iomxx4.h c:\avr-gcc-4.7.1-
3
rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/portpins.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/common.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/version
4
.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/fuse.h c:\avr-gcc-4.7.1-rc1-mingw32\bin\../lib/gcc/avr/4.7.1/../../../../avr/include/avr/lock.h

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wirklich zu erkennen, wo der ganze mingw-Kram her gezogen wird, ist
da leider nicht.  Meine Vermutung wäre, dass es irgendwie über
deine automatische Dependency-Generierung reinkommt.  Kommentier'
doch mal die letze Zeile aus.

von Stefan E. (sternst)


Lesenswert?

1
## Compile other asm files
2
$(ASRC:.S=.o): $(ASRC)
3
  $(CC) $(INCLUDES) $(ASMFLAGS) -c  $+
4
5
## Compile other c files
6
$(CSRC:.c=.o): $(CSRC)
7
  $(CC) $(INCLUDES) $(CFLAGS) -c  $+
Dein Problem ist das "$+".

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Die Pfade sehen ungesund aus:

c:avr-gcc-4.7.1-rc1-mingw32bin..

soll wohl sein:

c:/avr-gcc-4.7.1-rc1-mingw32/bin/..

D.h. Problem sind \ anstatt / als Pfadtrenner.  Evtl. geht auch die \ zu 
escapen, d.h. \\ verwenden.

von uze (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Kommentier' doch mal die letze Zeile aus.

Danke, das hat das Problem gelöst.

von Stefan E. (sternst)


Lesenswert?

uze schrieb:
> Jörg Wunsch schrieb:
>> Kommentier' doch mal die letze Zeile aus.
>
> Danke, das hat das Problem gelöst.

Nö, es hat nur die Symptome verschwinden lassen.
Dafür hast du jetzt das Problem, dass du bei einer Änderung an einem 
Header-File immer höllisch aufpassen musst, dass du danach kein 
einfaches "make" (oder "make all") machst, sondern immer ein "make 
clean; make".

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan Ernst schrieb:
> Nö, es hat nur die Symptome verschwinden lassen.

Ja.  Nun müsste man die Ursache klären.  Stammen die Dateien in dep/
eventuell von einem anderen System (Windows/Unix-Mischmasch)?  Dann
sollte sich das beheben lassen, indem man sie alle mal löscht und
neu anlegen lässt.

> Dafür hast du jetzt das Problem, dass du bei einer Änderung an einem
> Header-File immer höllisch aufpassen musst

Naja, es gab auch ein Leben vor dieser Art automatischer Dependency-
Generierung: man gibt einfach im Makefile alle Header-Abhängigkeiten
selbst an.

von Stefan E. (sternst)


Lesenswert?

Jörg Wunsch schrieb:
> Ja.  Nun müsste man die Ursache klären.  Stammen die Dateien in dep/
> eventuell von einem anderen System (Windows/Unix-Mischmasch)?  Dann
> sollte sich das beheben lassen, indem man sie alle mal löscht und
> neu anlegen lässt.

Der Mischmasch in den Pfaden in den Dependency-Files ist völlig normal, 
und dürfte das Resultat davon sein, dass der erste Teil des Pfades von 
einer Systemabfrage (nach dem aktuellen Directory) kommt, und der Rest 
vom Compiler beigesteuert wird.
Die eigentliche Ursache seiner Probleme ist seine Verwendung von "$+", 
was eine menge Zeugs auf die Kommandozeile pumpt, welches dort überhaupt 
nichts zu suchen hat.

von uze (Gast)


Lesenswert?

Stefan Ernst schrieb:
> Die eigentliche Ursache seiner Probleme ist seine Verwendung von "$+",
> was eine menge Zeugs auf die Kommandozeile pumpt, welches dort überhaupt
> nichts zu suchen hat.

Welches Symbol wäre dann sinvolller? Schließlich will ich in dieser 
Zeile mehrere Dateien kompilieren lassen.

von Stefan E. (sternst)


Lesenswert?

uze schrieb:
> Welches Symbol wäre dann sinvolller?

$<

uze schrieb:
> Schließlich will ich in dieser
> Zeile mehrere Dateien kompilieren lassen.

Und warum willst du es unbedingt anders machen als üblich, nämlich mit 
einer allgemeinen Regel die Dateien einzeln übersetzen zu lassen?

von uze (Gast)


Lesenswert?

Weil ich mich damit nicht auskenne. Ich habe $+ als Möglichkeit gesehen, 
mehrere Dateien zu kompilieren. Kannst du mir ein Beispiel für eine 
Regel für eine Liste von Dateien geben?

von hanfsamen (Gast)


Lesenswert?

uze schrieb:
> Weil ich mich damit nicht auskenne. Ich habe $+ als Möglichkeit gesehen,
> mehrere Dateien zu kompilieren. Kannst du mir ein Beispiel für eine
> Regel für eine Liste von Dateien geben?

Read the fine GNU make manual.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.