в результате разработок на С для контроллеров накопилось некоторое количество файлов-библиотек с часто используемыми функциями.
обычно нужные файлы кидаю в папку lib проекта. возникает проблема слежения за версиями этих файлов - получается куча одинаковых файлов разных версий в разных папках.
плюс проблема отслеживания изменений - например в текущем проекте происходит доработка/оптимизация одной/нескольких библиотек, нужно учесть эти изменения в других проектах, использующих эту библиотеку.

кто как решает ?

Сообщение отредактировал ukpyr - Sep 11 2009, 09:30

Пихать все в одну библиотеку (бинарную, .a). Есть большой недостаток - придется следить, чтобы изменения в какой-нибудь функции для одного проекта не поломали проект который был год назад.

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

В принципе можно просто использовать CVS и не заморачиваться с библиотекой, но это идеологически не верно.

Я завёл отдельный SVN-репозиторий для собственных библиотечных файлов.
При этом желательно правильно организовать его дерево каталогов, например по Target-ам (AVR, ARM, x86).
Далее просто время от времени добавляете в репозиторий свои библиотечные файлы и не забываете писать подробный commit.
Со временем у вас образуется база либов, которую вы сможете подключать к версионированным проектам (для SVN - externals)
Вообщем идея примерно такая.

P.S. Не обязательно использовать именно SVN, есть и другие системы контроля версий, выбираете какая вам больше нравиться.

я и веду репозиторий, но для каждого проекта - свой.
если либы будут в отдельной от проектов папке - как передавать такие исходники заказчику ?

Проще всего иметь один репозирорий. Тогда при передаче можно создать Tag и ничего не забудется.

Можно при передаче собирать все в одно место. Это не должно занимать много времени, но нужно сохранять результат где-то, чтобы знать что было отдано.

Если у вас система управления версиями Subversion, то вам правильно посоветовали - svn:externals. В проекте заводите отдельную директорию lib, как у вас и сделано, в свойствах прописываете svn:externals - путь к внешнему репозиторию, где хранятся эти общие файлы. При апдейте этой директории в нее будут помещены файлы из того внешнего репозитория. Все возможности по синхронизации этих файлов между проектами (через их репозиторий) у вас будут.

working copy файлов либов будут в папке с проектом (как сами пожелаете), а репозиторий, в котором они находятся может быть отдельный. Может быть также и общий репозиторий, это не столь важно, главное чтобы вам было удобно.

как раз вопрос в тему. про svn_externals выглядит это все красиво, но вот сейчас столкнулся вот с чем (работаю с ФПГА).

Есть у меня проект под названием "общие компоненты". Пока компоненты в нем были маленькие (занимали один файл) все было хорошо. Использовал я этот проект в N ом количестве других проектов, при этом ссылался на него как svn::external ../common_comp/trunk/rtl. Компоненты под проект не кастомизировались, но если в них находилась ошибка, то она исправлялась по месту + делался коммит в корневое дерево проекта общих компонентов.

Теперь нарисовался у меня компонент файлов на 10. из них в релиз идет только 7 файлов, т.к. остальные файлы рабочие, используемые при отладке. Также при разработке этого компонента был создан мини проект и его структуру хотелось бы сохранить для возможного устранения ошибок в будущем. Но в описанную выше технику использования либы этот многофайловый компонент, часть файлов которого не нужна, не вписывается. Действительно зачем при использовании компонента мной или кем то другим видеть файлы, которые для этого не нужны.

собственно вопрос, как грамотно обрулить данную ситуацию?

Я вижу пока только вариант сбора всех проектов общих компонентов в trunk в одной папке и релизы этих компонентов в tag. Правда в этом случае правка багов должна идти сложнее : правим в папке проекта общих компонентов, затем делаем очередной релиз, затем переписываем svn_externals. Но это как то коряво.

Может как то можно сделать псевдоним в SVN. Например я веду релизы и по псевдониму например CURRENT_RELEASE SVN вытаскивет нужный мне релиз и не потребуется ручками править svn_externals?

не претендую на грамотность
А может воспользоваться POST-COMMIT HOOK. Написать скрипт, который после коммита проекта с либой создаст tag, содержащий нужные файлы, который всегда будет связан svn:externals с проектом, в котром используется эта либа.
Таким образом вы правите тестовый проект, производите фиксацию, нужные файлы попадают в tag, который связан svn:externals с другим проектом.

P.S. Не бейте сильно, если чушь написал. я из благих намерений

данный вариант я обдумывал, вот что именно мне в нем не нравиться:
svn::externals может ссылаться только на одну и ту же папку и в данном случае, при каждом создании нового релиза(не важно скриптом или ручками) эту папку нужно прибивать и создавать заново. Насколько я понял книгу об SVN такое (постоянное убийство и создание папки) приемлимо в branch, но в tag не поощряется.
Минус также в том, что если в tag будет только одна эта папка, то потеряется история релизов(т.е. сложно будет сказать где релиз 1.0, а где 1.11), это может "выстрелить" в старом проекте, когда либа "ушла" слишком далеко. А если в tag будет лежать N релизов то это будет еще одна постоянная копия и мне кажеться что эта копия во первых лишняя, а во вторых она постоянно прибивается и создается заново.

пришло мне тут в голову решение, а что если воспользоваться командой Rename.
Например делаем релиз 1.0, помещаем его в папку tags/release. Если найден баг, то делаем версию 1.1. Переименовываем tag/release в tag_release_1.0 и на место tags/release закатываем версию 1.1. В этом случае на месте и история релизов и svn::externals всегда указывает на одну и ту же папку % )