심볼릭 링크에 대한 심볼릭 링크를 갖는 것이 비효율적입니까?

심볼릭 링크에 대한 심볼릭 링크를 갖는 것이 비효율적입니까?

우리는 하위 프로젝트 수준 포함 파일에 대한 심볼릭 링크가 있는 프로젝트 수준 포함 디렉터리를 원하는 일련의 Makefile을 설정하고 있습니다. 많은 하위 프로젝트 개발자들은 포함 파일이 실제 소프트웨어가 있는 또 다른 디렉터리에 대한 심볼릭 링크가 되도록 선택했습니다.

그래서 제 질문은 다른 파일에 대한 기호 링크(예: 컴파일 중에 수십 번 이상 포함될 수 있는 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

답변1

비효율적이라는 것이 무슨 뜻인지 잘 모르겠지만 내 생각에는 '아니요'입니다.

커널은 모든 심볼릭 링크를 처리하고, gnumake는 open()만 수행하고 파일을 가져옵니다. 모든 사용자 수준 앱은 심볼릭 링크인지 여부에 대해 신경 쓰지 않고(거의 신경 쓰지 않음) 파일만 가져옵니다.

커널이 통과해야 하는 추가 수준의 심볼릭 링크는 컴파일하고 디스크에 캐시를 쓰거나 플러시하는 시간에 비해 중요하지 않습니다.

관련 정보