Всем известны варианты подключения файла через #include:
либо указываем путь в #include (абсолютный или относительный), либо в #include указываем только имя файла, а путь к папке подсовываем компилятору через опцию -I.
Стоит задача выбора способа задания путей для большого проекта.
Вижу такие плюсы/минусы вариантов:

1. (прописать путь в #include )
+ возможность использования двух и более файлов с одинаковым именем в разных папках
+ при составлении Makefile не надо описывать кучу директорий в -I
+ если папок много, найти файл проще (по пути)
- для реорганизации расположения исходников придется переписать много #include-ов

2. (прописать в -I )
+ исходники можно реорганизовывать (перемещать по папкам) без необходимости править #include-ы
... (в общем в точности наоборот к первому варианту)

Расскажите пожалуйста свои с какими плюсами и минусами обоих вариантов вы встречались.

я обычно добавляю в проекты только стандартные пути (те, что по-умолчанию и буст) а также $(ProjectDir) и $(SolutionDir)
при этом простое правило - если файл находится в том же проете, то инклудится через #include ""
если это библиотечный или с другого проекта - то через #include<>

потому инклудов вида #include "../../Proj/file.h" у меня практически не бывает и мороки минимум

Alek86, т.е. Вы практикуете расположение всех исходных файлов проекта в одной директории?

нет, но вложенности не большие, потому к файлам легче обратиться через "корень"
потому я и сказал, что не бывает практически, то бишь редко 

если вы пишете как в джаве, с 3-4 вложенными неймспейсами, то, наверное, легче использовать ".."

Google C++ Style Guide рекомендует прописывать пути без переходов на уровень выше (..), а исключительно от корня проекта.
В совокупности с

выходит неплохое решение.
недостаток

решается поиском/заменой, так как теперь пути фиксированные и не содержат отличий (как в варианте с переходами по ".." ).

у меня стандартная картина расположения файлов:
libs\
src\Project.sln
src\Project1Dir\
src\Project2Dir\
...
tools\
bin\

все собирается в bin, в tools автосборщики, в lib все lib и нужные хедеры (например для xerces парсера есть папка xerces\внутри которой хедеры, сам же xerces.lib будет лежать в libs). Соотвественно -I указан (кроме буста, и прочих "стандартностей" еще и $(SolutionDir)/../libs/

достаточно удобно, кроме того "все в одном"....


зачастую в libs лежат архивы библиотек, которые надо распоковать. Девелопер распакует их сам (и если надо соберет).

Сама же сборка производится только конвеером с помощью скриптов в tools, при этом собираются и все библиотеки с libs. Собираются ибо хрен его знает какие там настройки компилятора будут на конвеере, да и сам компилятор хрен знает каких версий, сервис паков и т.д. - вобщем "от греха подальше".....


Если кто может предложить что-то более вразумительное, то с удовольствие послушаю

Добавлено через 2 минуты и 30 секунд
да, если есть два проекта, второй из которых зависит от первого, то, в случае использования subversion на него идет svn:externals в папке libs (т.о. он также скачивается в либы, и если надо собирается)....

такие же трюки можно провернуть и в mercurial\git\ваш_любимый_FVCS

jonie, а как ты досукиваешься до файлов с других проектов?

Alek86, прочитав внимательно, можно заметить добавленое.

в большинстве случаев, я, как программист, делаю вместо svn:externals на своей машине реальную soft-link ссылку на "другой проект", нежели скачиваю его "еще раз".
обычно "другой проект" содержит все свои include-ы в одной папке (имя которой обычно совпадает с именем проекта), на родителя которую делается -I проекта, ссылающегося на этот....

можно и в других системах делать такие же вещи, это не проблема вроде бы...

не очень понял
получается, что svn:externals как-то влияет на include directories в колмпилере?

Alek86, нет.
пусть у нас два проекта А и Б, Б зависит от А.
Тогда структура будет такая:



где libs\A подключен через svn:externals (поэтому там появитс src\А собственно).

Сам проект Б настроен так: -I $(SolutionDir)\..\libs\A\src\
в проекте Б, хедеры подключаются через include <A\megaheader.h>