Makefile, dépendances d'en-tête

Disons que j'ai un makefile avec la règle

%.o: %.c
 gcc -Wall -Iinclude ...

Je veux que * .o soit reconstruit chaque fois qu'un fichier d'en-tête change. Plutôt que d'élaborer une liste de dépendances, à chaque fois qu'un fichier d'en-tête /includechange, tous les objets du répertoire doivent être reconstruits.

Je ne peux pas penser à une bonne façon de changer la règle pour s'adapter à cela, je suis ouvert aux suggestions. Des points bonus si la liste des en-têtes ne doit pas être codée en dur

Si vous utilisez un compilateur GNU, le compilateur peut assembler une liste de dépendances pour vous. Fragment Makefile:

depend: .depend

.depend: $(SRCS)
        rm -f ./.depend
        $(CC) $(CFLAGS) -MM $^ -MF  ./.depend;

include .depend

ou

depend: .depend

.depend: $(SRCS)
        rm -f ./.depend
        $(CC) $(CFLAGS) -MM $^ > ./.depend;

include .depend

où SRCSest une variable pointant vers toute votre liste de fichiers source.

Il y a aussi l'outil makedepend, mais je ne l'ai jamais autant aimégcc -MM

La plupart des réponses sont étonnamment compliquées ou erronées. Cependant, des exemples simples et robustes ont été publiés ailleurs [ codereview ]. Certes, les options fournies par le préprocesseur gnu sont un peu déroutantes. Cependant, la suppression de tous les répertoires de la cible de construction avec -MMest documentée et non un bogue [ gpp ]:

Par défaut, CPP prend le nom du fichier d'entrée principal, supprime tous les composants du répertoire et tout suffixe de fichier tel que «.c», et ajoute le suffixe d'objet habituel de la plate-forme.

L' -MMDoption (un peu plus récente) est probablement ce que vous voulez. Pour être complet, un exemple de makefile qui prend en charge plusieurs répertoires src et des répertoires de construction avec quelques commentaires. Pour une version simple sans répertoire de compilation, voir [ codereview ].

CXX = clang++
CXX_FLAGS = -Wfatal-errors -Wall -Wextra -Wpedantic -Wconversion -Wshadow

# Final binary
BIN = mybin
# Put all auto generated stuff to this build dir.
BUILD_DIR = ./build

# List of all .cpp source files.
CPP = main.cpp $(wildcard dir1/*.cpp) $(wildcard dir2/*.cpp)

# All .o files go to build dir.
OBJ = $(CPP:%.cpp=$(BUILD_DIR)/%.o)
# Gcc/Clang will create these .d files containing dependencies.
DEP = $(OBJ:%.o=%.d)

# Default target named after the binary.
$(BIN) : $(BUILD_DIR)/$(BIN)

# Actual target of the binary - depends on all .o files.
$(BUILD_DIR)/$(BIN) : $(OBJ)
    # Create build directories - same structure as sources.
    mkdir -p $(@D)
    # Just link all the object files.
    $(CXX) $(CXX_FLAGS) $^ -o $@

# Include all .d files
-include $(DEP)

# Build target for every single object file.
# The potential dependency on header files is covered
# by calling `-include $(DEP)`.
$(BUILD_DIR)/%.o : %.cpp
    mkdir -p $(@D)
    # The -MMD flags additionaly creates a .d file with
    # the same name as the .o file.
    $(CXX) $(CXX_FLAGS) -MMD -c $< -o $@

.PHONY : clean
clean :
    # This should remove all generated files.
    -rm $(BUILD_DIR)/$(BIN) $(OBJ) $(DEP)

Cette méthode fonctionne car s'il existe plusieurs lignes de dépendance pour une seule cible, les dépendances sont simplement jointes, par exemple:

a.o: a.h
a.o: a.c
    ./cmd

est équivalent à:

a.o: a.c a.h
    ./cmd

comme mentionné à: Makefile plusieurs lignes de dépendance pour une seule cible?

Comme je l'ai posté ici, gcc peut créer des dépendances et compiler en même temps:

DEPS := $(OBJS:.o=.d)

-include $(DEPS)

%.o: %.c
    $(CC) $(CFLAGS) -MM -MF $(patsubst %.o,%.d,$@) -o $@ $<

Le paramètre '-MF' spécifie un fichier dans lequel stocker les dépendances.

Le tiret au début de '-include' indique à Make de continuer lorsque le fichier .d n'existe pas (par exemple lors de la première compilation).

Notez qu'il semble y avoir un bogue dans gcc concernant l'option -o. Si vous définissez le nom de fichier de l'objet sur obj / _file__c.o, le fichier généré .d contiendra toujours le fichier .o, pas obj / _file__c.o.

Que diriez-vous de quelque chose comme:

includes = $(wildcard include/*.h)

%.o: %.c ${includes}
    gcc -Wall -Iinclude ...

Vous pouvez également utiliser les caractères génériques directement, mais j'ai tendance à trouver que j'en ai besoin à plus d'un endroit.

Notez que cela ne fonctionne bien que sur les petits projets, car cela suppose que chaque fichier objet dépend de chaque fichier d'en-tête.

La solution de Martin ci-dessus fonctionne très bien, mais ne gère pas les fichiers .o qui résident dans des sous-répertoires. Godric souligne que l'indicateur -MT résout ce problème, mais il empêche simultanément le fichier .o d'être écrit correctement. Ce qui suit prendra en charge ces deux problèmes:

DEPS := $(OBJS:.o=.d)

-include $(DEPS)

%.o: %.c
    $(CC) $(CFLAGS) -MM -MT $@ -MF $(patsubst %.o,%.d,$@) $<
    $(CC) $(CFLAGS) -o $@ $<

Cela fera très bien le travail, et même gérer les sous-répertoires spécifiés:

    $(CC) $(CFLAGS) -MD -o $@ $<

testé avec gcc 4.8.3

Voici un deux lignes:

CPPFLAGS = -MMD
-include $(OBJS:.c=.d)

Cela fonctionne avec la recette de création par défaut, tant que vous avez une liste de tous vos fichiers objets dans OBJS.

Je préfère cette solution, à la réponse acceptée par Michael Williamson, elle détecte les modifications apportées aux sources + fichiers en ligne, puis aux sources + en-têtes, et enfin aux sources uniquement. L'avantage ici est que toute la bibliothèque n'est pas recompilée si seulement quelques modifications sont apportées. Ce n'est pas une considération énorme pour un projet avec quelques fichiers, mais si vous avez 10 ou 100 sources, vous remarquerez la différence.

COMMAND= gcc -Wall -Iinclude ...

%.o: %.cpp %.inl
    $(COMMAND)

%.o: %.cpp %.hpp
    $(COMMAND)

%.o: %.cpp
    $(COMMAND)

Ce qui suit fonctionne pour moi:

DEPS := $(OBJS:.o=.d)

-include $(DEPS)

%.o: %.cpp
    $(CXX) $(CFLAGS) -MMD -c -o $@ $<

Une version légèrement modifiée de la réponse de Sophie qui permet de sortir les fichiers * .d dans un dossier différent (je ne collerai que la partie intéressante qui génère les fichiers de dépendance):

$(OBJDIR)/%.o: %.cpp
# Generate dependency file
    mkdir -p $(@D:$(OBJDIR)%=$(DEPDIR)%)
    $(CXX) $(CXXFLAGS) $(CPPFLAGS) -MM -MT $@ $< -MF $(@:$(OBJDIR)/%.o=$(DEPDIR)/%.d)
# Generate object file
    mkdir -p $(@D)
    $(CXX) $(CXXFLAGS) $(CPPFLAGS) -c $< -o $@

Notez que le paramètre

-MT $@

est utilisé pour garantir que les cibles (c'est-à-dire les noms de fichier objet) dans les fichiers * .d générés contiennent le chemin complet des fichiers * .o et pas seulement le nom du fichier.

Je ne sais pas pourquoi ce paramètre n'est PAS nécessaire lors de l'utilisation de -MMD en combinaison avec -c (comme dans la version de Sophie ). Dans cette combinaison, il semble écrire le chemin complet des fichiers * .o dans les fichiers * .d. Sans cette combinaison, -MMD écrit également uniquement les noms de fichiers purs sans aucun composant de répertoire dans les fichiers * .d. Peut-être que quelqu'un sait pourquoi -MMD écrit le chemin complet lorsqu'il est combiné avec -c. Je n'ai trouvé aucun indice dans la page de manuel g ++.