rezident 0 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба В корневых хидерах у меня находятся такие глобальные и немодифицируемые вещи как, например, типы переменных. А то, что как-то платформеннозависимо и/или подвергается модификации в проектах не должно находиться в корне. Например, если у вас определен адрес вызова глобальной функции, то в модифицируемых версиях извольте выкручиваться за счет каких-то дополнительных проверок внутри самой функции, а адрес вызова не трожьте! Как учил меня коллега, писавший операционки начиная с конца 80-х годов, в описании каждого модуля должен быть текстовый комментарий состояния его. Примерно что-то типа такого 1) не подлежит модификации, 2) модифицируемый только в исключительном случае, 3) утвержден для публикации, 4) подлежит утверждению, 5) в разработке, 6) альфа-версия. И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее. P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба То ли я не умею готовить, но у меня вот эти две папки |->_INC <-общие хидеры проектов |->_SRC <-общие исходники проектов не получаются статическими, они тоже изменяются. В реальной жизни то ошибка находится, то ли стремление улучшить проснется. :05: Получается такая последовательность: - общая часть ver 1 - проект A ver 1 - проект B ver 1 Произвели 100 устройств проекта A. - корректировали общую часть ver 2 - корректировали проект 2 Произвели 100 устройств по проекту B. Корректировали проект A ver 2. Произвели 100 устройств проекта A Пришла жалоба от клиента по ошибке в проекте A из первой партии. Начинаем разбираться. Вернули версию проекта A на 1 - все правильно. Но результат компиляции другой, так как была изменена общая часть. Концов не осталось. В общем, может это уже и не в топик данной темы, но все же отвечаю. Чтобы такого как у вас не случалось, общие части, которые могут быть использованы в разных проектах должны в каждом проекте иметь свои локальные копии, находящиеся под контролем системы 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". Результат компиляции до байта совпадает. Конец найден, и виноватый тоже :) И если проект ведет более, чем один программист, то данная концепция просто необходима. Система контроля версий это конечно хорошо, но согласованность при разработке в команде важнее. P.S. конечно в проектах, которые выполняю единолично, я позволяю себе больше вольностей ;) Если проект ведет более чем один программист система контроля версий - суровая необходимость. Иначе: - Вася, ты менял исходник в таком то каталоге? - Да, тебе кинуть? - Конечно, еще месяц назад надо было. - Да я же в отпуске был. Блин, сетевой каталог не открывается, давай флешку... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба Конец найден, и виноватый тоже :) Ну, с виноватыми обычно проблем не бывает :) Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал. Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба Ну, с виноватыми обычно проблем не бывает :) Признаюсь, инструкцию по SVN курил "не в затяжку", пользуюсь очевидными функциями. Про такую комбинацию не думал. Мне кажется, что могут быть проблемы, если отмотать версию в такой локальной копии common назад и случайно закоммитить. Но нужно подумать и попробовать. Спасибо. Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи :). И в данный момент она недокурена пока. В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 35 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба Я пользуюсь на данный момент CVS, как оно реализуется в SVN не совсем представляю, поскольку доку по SVN меня несколько насильно заставили покурить некоторые присутвующие в том числе здесь товарищи :). И в данный момент она недокурена пока. Вот и плохо! :) Но тебя раззи заставишь, если ты не хошь... В CVS при извлечении по тэгу локальную версию закомитить будет нельзя, поскольку на ней будут так называемые липкие метки. Если нужно будет, допустим, выпустить релиз на основе именно этой комбинации исходников, ну типа исправить только тот небольшой баг, то тогда делается ветвь в проекте на основе текущей версии извлеченных исходных текстов и она уже комитится, но не мешает основному стволу разработки. При желании потом изменения можно внести на ствол. В Subversion принципиально это не отличается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fmdost 0 17 октября, 2007 Опубликовано 17 октября, 2007 · Жалоба Спасибо за такое количество ответов! Чтобы пути были относительно проекта, можно использовать $PROJ_DIR$, примерно так: ..\$PROJ_DIR$\ОбщиеФайлы\ Только что проверил, в #include "" работает и полный и относительный путь. Слэши не забыли проэкранировать? Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Johnny81 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба Беру путь из заголовка в окошке. Что значит "Слэши проэкранировать?" #include "c:\\folder1\\folder2\\myFile.h" #include "..\\..\\folder2\\myFile.h" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolaKirov 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба Не нада екранироват :) Вот и пример из рабочего проекта #if IMPLEMENT_USART_LIB == 1 #include ".\libs\Usart_2.c" #endif #if IMPLEMENT_SPP_LIB == 1 #include ".\libs\SPP.c" #endif #if IMPLEMENT_EELOG_LIB == 1 #include ".\libs\EElog.c" #endif #if IMPLEMENT_DS1338_LIB == 1 #include ".\libs\DS1338.c" #endif #if IMPLEMENT_I2C_LIB == 1 #include ".\libs\i2c.c" #endif #if IMPLEMENT_I2C_SOFT_LIB == 1 #include ".\libs\i2c_soft.c" #endif #if IMPLEMENT_ADC_LIB == 1 #include ".\libs\ADC_2.c" #endif #if IMPLEMENT_I2CEEPROM_LIB == 1 #include ".\libs\i2ceeprom.c" #endif А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения? Не получается никак у меня. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба А у меня ест вопрос. Возможно ли в сорс използовать переменньi окружения? Нет, конечно, но их можно и нужно использовать для передачи параметров компилятору через командную строку. Какие проблемы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolaKirov 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба Нет проблем. Хотелос написат что то типа #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" куда SOURCE_CODE_DIR переменная окружения. Но ето вообщем не работает в никаком компиляторе. Но можно жит и без етого :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба Хотелос написат что то типа #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" Компилятору в командную строчку что-то типа -I $SOURCE_CODE_DIR$ И все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolaKirov 0 18 октября, 2007 Опубликовано 18 октября, 2007 · Жалоба Да ето и ползуюс. Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories ето включает их точно с -I. но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше :):):) Но уви.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 19 октября, 2007 Опубликовано 19 октября, 2007 · Жалоба Да ето и ползуюс. Но делаю из опции проекта -> C/C++ Compiler -> Preprocessor -> Additional include directories ето включает их точно с -I. но #include "$SOURCE_CODE_DIR$\ARM\ATMEL\i2c.c" нравится болше :):):) Но уви.... Мне вот вообще больше нравится #include "i2c.h" безотносительно того, где оно там закопано, в каких папках проекта. Поэтому опция -I в этом отношении рулит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
NikolaKirov 0 19 октября, 2007 Опубликовано 19 октября, 2007 · Жалоба Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 19 октября, 2007 Опубликовано 19 октября, 2007 · Жалоба Но если окажется что в прописаньих через -I пути ест 2 фаил с ето имя,будет използоватся первъи из них кто компилер нашел. Для маленких проект ето не проблем но когда проект становится болшой и вероятност таких проблем возрастает. Это уже проблема организации структуры проетка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
