2

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:

/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 Answer 1

2

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.

2
  • 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. Feb 4, 2011 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. Feb 4, 2011 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .