Как управлять полезными модулями и фрагментами кода с помощью git, boost,

Question

При программировании я накапливаю фрагменты кода и классы полезности. Я хочу сохранить их для практического использования в будущем.

Вопрос вкратце - это лучший способ сделать это. Более подробно с примером:

При написании кода мы продолжаем многократно использовать наши приятные лакомые кусочки для покрытия общих задач. Однако, чтобы сделать наши проекты с открытым исходным кодом, скажем, с git на github, эти лакомые кусочки также должны быть доступны. Мне было интересно, как это сделать лучше всего.

• Могу ли я сделать свое личное коммунальное репо, которое проекты могут добавлять в качестве подмодулей в git?
• Или я делаю отдельные git-репозитории для каждого лакомого кусочка, поэтому проект может добавить определенную версию конкретного лакомого кусочка в качестве подмодуля. (это касается проблемы с библиотеками-утилитами, такими как boost, которые становятся огромными, даже если ваша программа может потребовать лишь небольшую часть)
• Или я объединил оба средства в ao утилиту repo с подмодулями, где внешние проекты могут иметь утилиту repo как подмодуль? Что произойдет, если они захотят использовать версию x tidbit a и версию y tidbit b? Может быть, просто иметь централизованный обзор?

Как и весь открытый код, такие фрагменты должны быть легкими, быстрыми, проверенными, переносимыми, документально и предпочтительно относительно автономными. Теперь я нахожу этот хороший код где-то, и он использует CTASSERT, который не переносится.

Что мне делать?

• я могу использовать повысить static_assert, но это добавляет большую зависимость к небольшому фрагменту кода, потому что повышение не является тривиальным, и на моей системе она составляет около 2 Гб. Чтобы усугубить ситуацию, он также добавляет эту зависимость для каждого проекта, используя фрагмент, который обеспечивает некоторые довольно простые функции. Кроме того, увеличение, насколько я знаю, не имеет git-репо, поэтому проект не может автоматически позаботиться об этих зависимостях с подмодулем.
• Делаю ли я еще один фрагмент и вытягиваю свое собственное время компиляции с глупым побочным эффектом заново изобретающего колеса и создавая больше кода, делающего то, что уже усиливает.

Im с нетерпением жду, как вы решаете эту проблему, а также общие мысли и рекомендации.

Answer 1

В этом, кажется, мало анимации, но я все еще очень взволнован и надеюсь на ввод идей от других. Это то, что я придумал:

Мотивация

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

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

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

Реализация

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

У меня есть одно хранилище TidBits_Cpp. Этот репозиторий имеет подмодули с каждым фрагментом кода.

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

Каждый подмодуль со сниппетом имеет в основном только заголовок с заголовком для модульного тестирования и автономное тестовое приложение.

Единичный базовый класс тестирования также является TidBit. Основное репо имеет приложение для тестирования модулей, которое проверяет все TidBits, которые существуют в системе. Для этого у него есть каталог с фиктивным включением, который должен быть последним в пути включения, поэтому вы всегда можете скомпилировать. Проверка определяет, позволяет узнать, какой код действительно доступен для модульного тестирования.

Весь код в подмодулях предполагает, что центральная директория включения находится в пути включения.

В репозиторий включены DoxyFiles, а также визуальные студийные решения. Eclipse сложнее, потому что он плохо работает с проектами, использующими файлы cpp из разных каталогов. Я добавлю MakeFiles позже для других компиляторов и платформ.

Чтобы получить полную мощность от этого, любой проект, который хочет использовать TidBit, должен включать подмодуль, указывающий на основной репозиторий TidBits_Cpp, а затем вытаскивать подмодули, которые они хотят использовать. Они могут сразу запускать все модульные тесты без написания кода, а затем просто начать кодирование.

Накладные расходы от родительского репо невелики, так как он содержит только одну строку, а также 1 папку с некоторыми элементами тестирования и DoxyFile.

Красота такого рода систем заключается в том, что репозитории фрагментов не нужны даже самим. Я могу позвонить в любой репозиторий github в качестве подмодуля, а так же может быть другой

Учитывая статичное утверждение, ну, я сделал свой собственный, хотя есть решения, доступные здесь, без необходимости добавлять boost в качестве зависимости для кода сниппет. Основными причинами, по которым я бы этого не делал, является то, что boost большой, и он недоступен как репозиторий git, поэтому он не может автоматически загружаться в качестве подмодуля.

Однако, поскольку Georg Fritzsche указал here, можно извлечь деталь из boost с помощью bpc. Недостаток заключается в том, что для статического утверждения, например, это все равно означает 70 файлов ...

Если вас это интересует, это the link to my repository, однако учтите, что на данный момент это не более чем иллюстрации к этому сообщению. Кодекс, находящийся там прямо сейчас, все еще находится в стадии разработки и еще не подходит для публичного выпуска. Также нет документации и т. Д. Все это для будущих времен.