В корневых хидерах у меня находятся такие глобальные и немодифицируемые вещи как, например, типы переменных. А то, что как-то платформеннозависимо и/или подвергается модификации в проектах не должно находиться в корне. Например, если у вас определен адрес вызова глобальной функции, то в модифицируемых версиях извольте выкручиваться за счет каких-то дополнительных проверок внутри самой функции, а адрес вызова не трожьте! Как учил меня коллега, писавший операционки начиная с конца 80-х годов, в описании каждого модуля должен быть текстовый комментарий состояния его. Примерно что-то типа такого
1) не подлежит модификации,
2) модифицируемый только в исключительном случае,
3) утвержден для публикации,
4) подлежит утверждению,
5) в разработке,
6) альфа-версия.
И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее.
P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей

В общем, может это уже и не в топик данной темы, но все же отвечаю.
Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы CVS (или подобной).
Именно система контроля версий и позволяет это сделать достаточно безболезненно, а вот если вы не пользуете систему контроля версий, тогда действительно синхронизировать общие исходники для разных проектов - тот еще гемор.
В этом случае будет примерно так:
- выпустили релиз проекта A ver 1 "А1" (с общей частью "common 1")
- выпустили релиз проекта В ver 1 "В1" (с общей частью "common 1")
"А1" и "В1" здесь надо воспринимать как тэги, однозначно идентифицирующие набор всех файлов проекта, как из common части, так и из файлов, относящихся исключительно к проекту.

Произвели 100 устройств проекта A, релиз "А1".

- корректировали общую часть на "common 2" в проекте В.
- выпустили релиз проекта В ver 2 "В2" (с общей частью "common 2")
Произвели 100 устройств по проекту B, релиз "В2".

- приступили к коррекции проекта "А", до кучи обновили common часть на "common 2".
- выпустили релиз проекта А ver 2 "А2" (с общей частью "common 2")
Произвели 100 устройств проекта A, релиз "А2".

Пришла жалоба от клиента по ошибке в проекте A с релизом "А1".
Начинаем разбираться. Извлекли версию проекта а по тэгу релиза "А1".
В локальной копии будут присутствовать исходники common версии "common 1".
Результат компиляции до байта совпадает. Конец найден, и виноватый тоже





Если проект ведет более чем один программист система контроля версий - суровая необходимость.
Иначе:
- Вася, ты менял исходник в таком то каталоге?
- Да, тебе кинуть?
- Конечно, еще месяц назад надо было.
- Да я же в отпуске был. Блин, сетевой каталог не открывается, давай флешку...

Ну, с виноватыми обычно проблем не бывает
Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал.
Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо.

Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи . И в данный момент она недокурена пока.
В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол.

Вот и плохо! Но тебя раззи заставишь, если ты не хошь...


В Subversion принципиально это не отличается.

Спасибо за такое количество ответов!


Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?"

#include "c:\\folder1\\folder2\\myFile.h"
#include "..\\..\\folder2\\myFile.h"

Не нада екранироват
Вот и пример из рабочего проекта


А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения?
Не получается никак у меня.

Нет, конечно, но их можно и нужно использовать для передачи параметров компилятору через командную строку. Какие проблемы?

Нет проблем. Хотелос написат что то типа

#include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c"

куда SOURCE_CODE_DIR переменная окружения. Но ето вообщем не работает в никаком компиляторе.
Но можно жит и без етого

Компилятору в командную строчку что-то типа -I $SOURCE_CODE_DIR$
И все.

Да ето и ползуюс.
Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories

ето включает их точно с -I.

но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше Но уви....

Мне вот вообще больше нравится
#include "i2c.h"
безотносительно того, где оно там закопано, в каких папках проекта.
Поэтому опция -I в этом отношении рулит.

Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает.

Это уже проблема организации структуры проетка.