Question: I googled but there's no answer... I have tried etags but I wonder if there's any more equivalent. Thanks.

Answer: 
A structure that we use on my workplace is having one "External" folder that contains an "Include" and a "Lib" folder for the headers and external Libs. However, as we also use VS, we try to use its "Dependencies" feature as most as possible, removing manual inputs to the linker. That means only projects that are not under the same solution goes to the "External" folder. Also, as we have some third-party libraries specific to some projects, we create folders inside the project folder for these includes and libs. This is how it gets:

```

.\
|-Project1\ --> contains Project1.vcproj
|-Project2\ --> contains Project2.vcproj
| |-Third-Party\
|   |-Include\
|   |-Lib\
|-External\
| |-Include\
| |-Lib\
|-InternalLibrary\ --> contains InternalLibrary.vcproj
|-Solution.sln --> includes the vcproj's and link them as necessary by its dependencies

```

I can't tell if this is the best structure ever, but everything is under source control, we can do night builds just by building the solution, and development goes by building single projects.
I've seen groups do the following:

* Separate internal code from external code (code they made vs external companies)
* Separate their code from library code
* Separate each program and each library
* Check in a compiled version of their dependencies, so it isn't a part of their full build cycle (at least, not in some branches. Other branches might do a more complete build)

Projects existed for each exe or library, in the directory with the exe/library.

Solutions existed wherever the teams felt it would be beneficial, and binaries were often linked, rather than their projects included in the sub-solutions. Only a full build was guaranteed not to break on a fresh enlistment.

Caveat emptor...