Мы настраиваем серию Make-файлов, где мы хотим иметь уровень проекта, включают каталог, который будет иметь символьные ссылки на уровень подпроекта, включают файлы. Многие разработчики подпроекта приняли решение иметь их включать файлы также быть символьными ссылками на еще один каталог, где фактическое программное обеспечение расположено.
Таким образом, мой вопрос, действительно ли это неэффективно, чтобы иметь символьную ссылку на символьную ссылку на другой файл (для, скажем, заголовка C++, который может быть включенными десятками или больше раз во время компиляции)?
Дерево каталогов в качестве примера:
/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
Не уверенный то, что Вы имеете в виду неэффективный, но мое предположение, является 'нет'.
Ядро обрабатывает все символьные ссылки, gnumake просто делает открытое (), и это получает файл. Любое приложение уровня пользователя не заботится (хорошо, редко уходы) о том, является ли это символьной ссылкой или нет, это просто получает файл.
Дополнительные уровни символьных ссылок, которые должно перейти ядро, незначительны по сравнению со временем, чтобы скомпилировать и писать/сбрасывать кэш в диск.