Wir richten eine Reihe von Makefiles ein, in denen wir ein Include-Verzeichnis auf Projektebene haben möchten, das symbolische Links zu Include-Dateien auf Unterprojektebene enthält. Viele Entwickler von Unterprojekten haben sich dafür entschieden, ihre Include-Dateien auch als symbolische Links zu einem weiteren Verzeichnis zu verwenden, in dem sich die eigentliche Software befindet.
Meine Frage lautet also: Ist es ineffizient, einen symbolischen Link zu einem symbolischen Link zu einer anderen Datei zu haben (beispielsweise für einen C++-Header, der während einer Kompilierung Dutzende oder mehr Mal eingefügt werden kann)?
Beispiel eines Verzeichnisbaums:
/project/include/
x_header1.h -> /project/src/csci_x/include/header1.h
x_header2.h -> /project/src/csci_x/include/header2.h
/project/src/csci_x/
include/
header1.h -> /project/src/csci_x/local_1/cxx/header1.h
header2.h -> /project/src/csci_x/local_2/cxx/header2.h
local_1/cxx/
module1.cpp
header1.h
local_2/cxx/
module2.cpp
header2.h
Antwort1
Ich bin nicht sicher, was Sie mit „ineffizient“ meinen, aber ich vermute „nein“.
Der Kernel verarbeitet alle Symlinks, gnumake führt einfach ein open() aus und holt die Datei. Apps auf Benutzerebene ist es egal (oder zumindest selten), ob es sich um einen Symlink handelt oder nicht, sie holt einfach die Datei.
Die zusätzlichen Ebenen an symbolischen Links, die der Kernel durchlaufen muss, sind im Vergleich zur Zeit zum Kompilieren und Schreiben/Leeren des Cache auf die Festplatte unbedeutend.