2017-09-17 4 views
0

Je viens suis tombé sur cette makefile, et il est source de confusion pour moi:Confondre Makefile

PROJECT_ROOT = ../.. 

LIBDIR = $(PROJECT_ROOT)/src/lib 

INCDIR = $(PROJECT_ROOT)/include 

SRCS = proj_start.c function1.c 
LIBS = $(LIBDIR)/libtest.a 

OBJS = $(SRCS:.c=.o) 
PROJECT = project1 
FLAGS = -I$(INCDIR) 
CC = gcc $(FLAGS) 

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

$(PROJECT): $(OBJS) 
     $(CC) $(OBJS) $(LIBS) -o [email protected] 

it: $(PROJECT) 

clean: 
     rm -f $(OBJS) $(PROJECT) 

depend: $(SRCS) 
     $(CC) -M $(SRCS) > dependList 
     sed -e '1,/^# DO NOT DELETE/!d' Makefile > make.tmp 
     cat dependList >> make.tmp 
     mv make.tmp Makefile 
     rm dependList 

# DO NOT DELETE THIS LINE 

Ce sont les parties qui me confondent:

LIBDIR = $(PROJECT_ROOT)/src/lib 

Pourquoi est-LIBDIR à la racine/src/lib bibliothèque? Ne devrait-il pas s'agir du répertoire racine/lib (les deux répertoires sont présents dans la hiérarchie des fichiers)?

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

Que diable est-ce que cela fait? Le "$ <" évalue à .c.o? Je vois que c'est une 'règle du suffixe' mais à quoi servent-ils vraiment?

depend: $(SRCS) 
     $(CC) -M $(SRCS) > dependList 
     sed -e '1,/^# DO NOT DELETE/!d' Makefile > make.tmp 
     cat dependList >> make.tmp 
     mv make.tmp Makefile 
     rm dependList 

# DO NOT DELETE THIS LINE 

Pourquoi avons-nous besoin de cette pièce? Il semble que toutes les dépendances ont déjà été traitées ...?

Répondre

0
  1. Oui, mettre lib/ sous src/ ressemble à une mauvaise conception, contre-intuitif.

  2. Ce:

    .c.o: ...

est the old way d'écrire une règle implicite. Ces jours-ci nous écrirait comme ceci:

%.o: %.c 
    ... 
  1. Il est une manière légèrement Rube Goldberg (I.R. intelligent, mais trop compliqué) de faire la manipulation automatique des dépendances. Donc, si foo.c contient la ligne #include bar.h, cette règle ajoutera la ligne foo.o: bar.h au fichier makefile. Ceci est réellement important.