We're setting up a series of Makefiles where we want to have a project-level include directory that will have symbolic links to sub-project-level include files. Many sub-project developers have chosen to have their include files also be symbolic links to yet another directory where the actual software is located.

So my question is, is it inefficient to have a symbolic link to a symbolic link to another file (for, say, a C++ header that may be included dozens or more times during a compile)?

Example directory tree:

                 x_header1.h -> /project/src/csci_x/include/header1.h
                 x_header2.h -> /project/src/csci_x/include/header2.h
                            header1.h -> /project/src/csci_x/local_1/cxx/header1.h
                            header2.h -> /project/src/csci_x/local_2/cxx/header2.h

Not sure what you mean inefficient, but my guess is 'no'.

The kernel handles all the symlinks, gnumake just does an open() and it gets the file. Any user level app doesn't care (well, rarely cares) about whether it's a symlink or not, it just gets the file.

The extra levels of symlinks the kernel needs to go through are insignificant vs. the time to compile and write/flush cache to disk.

  • I was looking for a gut feel as to if the extra layer of sym links winds up in more i/o hits, but I think your explanation about how the kernel handles the links works for me. – Ogre Psalm33 Feb 4 '11 at 18:02
  • @Ogre yes it does, but the fs may cache it, and it's dwarfed by all the other i/o. It's basically an extra lstat() for each level of symlinks, which is nothing compared to all your writes. – Rich Homolka Feb 4 '11 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.