2009-03-20 35 views
11

he construido un archivo make para mi proyecto, y funciona (todo se compila) pero da estos mensajes de error irritantes:¿Por qué se queja de dependencias circulares?

make: Circular zpr.c <- zpr.o dependency dropped. 
gcc -Wall -c -o zpr.o zpr.c 
make: Circular readjpeg.c <- readjpeg.o dependency dropped. 
gcc -Wall -c -o readjpeg.o readjpeg.c 
make: Circular readppm.c <- readppm.o dependency dropped. 
gcc -Wall -c -o readppm.o readppm.c 
make: Circular SceneNode.cpp <- SceneNode.o dependency dropped. 
g++ -c -o SceneNode.o SceneNode.cpp 
make: Circular BoundingBoxNode.cpp <- BoundingBoxNode.o dependency dropped. 
g++ -c -o BoundingBoxNode.o BoundingBoxNode.cpp 
make: Circular GeometryNode.cpp <- GeometryNode.o dependency dropped. 
g++ -c -o GeometryNode.o GeometryNode.cpp 
make: Circular SceneGraph.cpp <- SceneGraph.o dependency dropped. 
g++ -c -o SceneGraph.o SceneGraph.cpp 
make: Circular testgraph.cpp <- testgraph.o dependency dropped. 
g++ -c -o testgraph.o testgraph.cpp 

Mi makefile no es complicado en absoluto, así que espero que alguien pueda detectar el error.

GXX=g++ 
CC=gcc 
CFLAGS=-Wall 

LIBS=-lGL -lglut -ljpeg 

OBJS=helpers.o loadobj.o zpr.o readjpeg.o readppm.o SceneNode.o BoundingBoxNode.o GeometryNode.o SceneGraph.o testgraph.o 
OBJS2=testgraph.o SceneGraph.o GeometryNode.o BoundingBox.o SceneNode.o readppm.o readjpeg.o zpr.o loadobj.o helpers.o 
SRCS=testgraph.cpp SceneGraph.cpp SceneNode.cpp 

.o.cpp: 
    $(GXX) $(CFLAGS) -c $< 

.o.c: 
    $(CC) $(CFLAGS) -c $< 

testgraph: $(OBJS) 
    $(GXX) $(LIBS) $(OBJS) -o testgraph 

clean: 
    rm *.o 

Respuesta

17

Sus reglas implícitas son las culpables. Tienen las extensiones enumeradas en el orden inverso de cómo las entiende make.

.o.c: 

dice que los archivos .c se crean a partir de archivos .o. Como ya existe una regla que dice que los archivos .o se crean a partir de archivos .c, tiene una dependencia circular y, por lo tanto, los errores.

La solución es (o debería ser, asumiendo una marca configurada razonablemente) simple.

No necesita (generalmente) especificar sus propias reglas de compilación en casos muy comunes, como las fuentes de C++. Sería más sencillo simplemente especificar algo como:

CFLAGS=-Wall 
LOADLIBES=-lGL -lglut -ljpeg 

OBJS=helpers.o loadobj.o zpr.o readjpeg.o readppm.o SceneNode.o \ 
    BoundingBoxNode.o GeometryNode.o SceneGraph.o testgraph.o 

all: testgraph 

testgraph: $(OBJS) 

Es probable que también lo ayude a evitar dos errores.

  1. Las reglas que escribió dicen que los archivos .o se crean a partir de archivos .c, que es al revés. Pero las reglas correctas ya existen en casi todas las versiones de make.

  2. Ha enumerado las bibliotecas antes que los archivos del objeto. Esto funciona por accidente en algunas plataformas que usan objetos de formato ELF. Pero todavía está mal. Enumere las bibliotecas después de los objetos porque las bibliotecas solo se cargan para satisfacer las características externas indefinidas.

+0

Muchas gracias, que eliminó los mensajes de dependencia circulares. Descubrí que también había una variable CXXFLAGS, por lo que también funciona. gcc se usa para C y g ++ para C++, como lo quiero. Pero, ¿por qué usa "cc" para vincular? ¿Debo preocuparme? –

+0

Dado que es probable que cc sea un enlace a gcc, eso estaría bien. Estoy bastante seguro de que tanto gcc como g ++ vincularán una aplicación mixta sin problemas. Sin embargo, la opinión generalizada es que se debe usar un controlador de compilador C++ en lugar de un controlador C para vincular código mixto. – RBerteig

+0

pero probablemente no hará un seguimiento de las dependencias. –

Cuestiones relacionadas