Я собираюсь открытый исходный код проект C++ на SourceForge. Я могу получить некоторые подсказки относительно организации кода?
Я собираюсь загрузить проект, я продолжал работать на SourceForge под GPL, и надеялся надеть некоторый совет, как организовать код способом, который легко понять и использовать любыми разработчиками, которые могли бы посмотреть на него, который работает хорошо с мерзавцем и способом, которым SourceForge представляет вещи.
Мои проекты являются межплатформенным приложением C++ и состоят из следующего:
- Часть библиотеки, которая делает фактическую работу
- Отдельная часть GUI, которая использует часть библиотеки
- Библиотеки с открытым исходным кодом, чьи включают пути, необходимы для компиляции библиотеки
- Измененные библиотеки с открытым исходным кодом, которые были изменены и следовательно находятся в некотором смысле прямая часть этого проекта также
- Скомпилированный вывод всех библиотек
Что лучший способ состоит в том, чтобы организовать это?
При работе над ним самостоятельно, от корня проекта у меня есть он как это:
/LibPortion
/GuiPortion
/libs/open исходные библиотеки
/libs/modified библиотеки с открытым исходным кодом
/libs/compiled/содержать скомпилированные библиотеки, включая при компиляции для Windows некоторых, которые не являются из библиотек с открытым исходным кодом, таких как файлы библиотеки Cygwin
Действительно ли это - разумный способ организовать вещи? Это соответствует конвенциям и ожиданиям?
При регистрации в моем проекте имеет смысл регистрироваться в библиотеках с открытым исходным кодом, а также части проекта? Я полагаю, что имеет смысл делать так, потому что это минимизирует трение с подъемом набора проекта и выполнением для нового dev. Конечно, я должен, по крайней мере, зарегистрироваться в измененных библиотеках с открытым исходным кодом.
Кроме того, что имеет смысл включать в репозиторий под скомпилированными библиотеками? Я думаю, что могло бы быть лучше сказать мерзавцу игнорировать тот каталог и оставлять это пустым, так как его содержание будет отличаться на каждой цели сборки, так как мой проект является межплатформенным.
Однако это также кажется действительно хорошим для людей, которые не хотят изводить с созданием и/или загрузкой всех библиотек самих для предложения библиотек, предварительно скомпилированных для основных платформ. Что самый умный путь состоит в том, чтобы также совместно использовать их? Я смотрю на SourceForge, и для меня не с готовностью очевидно, как я должен совместно использовать их если не как часть моего репозитория мерзавца.
3 ответа
В общем, отделите свою работу от работы третьих лиц.На самом базовом уровне ваша корневая папка может выглядеть так:
|- GUI
|- Library
|- Third-party
|- lib
|- source
Я разделил «стороннюю» папку на две подпапки в целях соответствия лицензии и простоты использования. Как именно вы будете распространять сторонние библиотеки, полностью зависит от их лицензий. Настройте свои make-файлы так, чтобы скомпилированные библиотеки попадали в папку стороннего разработчика \ lib (куда вы также будете помещать любые предварительно скомпилированные библиотеки). Таким образом, пользователь может загрузить предварительно скомпилированные библиотеки и проигнорировать папку source или загрузить исходный код и проигнорировать папку lib в зависимости от того, хотят ли они перестроить сторонние библиотеки.
Если вам необходимо распространять вашу измененную версию в виде двоичного кода и исходного кода, тогда вам нужно будет разместить измененную версию в репозитории исходного кода (по вашему выбору будет предоставлена предварительно скомпилированная библиотека).
Если вы используете немодифицированную библиотеку и репозиторий Subversion (или аналогичный), вы можете использовать свойство externals , чтобы связать свой репозиторий с репозиторием сторонней библиотеки таким образом, чтобы когда пользователь копия вашего исходного кода, он берет исходный код библиотеки из своего собственного репо. Таким образом, вам не нужно держать локальное зеркало источника библиотеки. В зависимости от того, какая сторонняя библиотека доступна в своем репо, вы также можете использовать внешние ссылки для ссылки на предварительно скомпилированную версию сторонней библиотеки. Это не только уменьшит объем кода, который вам придется разместить в своем репо, но также будет более четко указывать на то, что конкретная сторонняя библиотека не была изменена.
При использовании немодифицированных библиотек было бы даже лучше вообще не включать исходный или двоичный код в ваше дерево исходных текстов. Просто отметьте в своей документации, что ваш проект зависит от библиотеки X (укажите также версию, если это важно), и укажите ссылку на домашнюю страницу проекта этой библиотеки / страницу / репозиторий Sourceforge. Позвольте разработчику решить, хотят ли они скомпилировать библиотеку, загрузить предварительно скомпилированную версию или, возможно, использовать уже установленную версию. Это означает, что вы также не можете предполагать, что библиотека или ее заголовки будут существовать в определенном каталоге относительно вашего исходного кода; вместо этого вам придется доверить пользователю установку библиотек там, где компилятор может их найти. Ваш код будет просто предполагать, что они находятся в пути поиска компилятора.
Также возможно, что ваши измененные библиотеки реализованы таким образом, что свойство externals приведет к извлечению неизмененного источника из стороннего репо, и ваша система сборки может применить исправление, содержащее ваши изменения. Таким образом, вы технически не распространяете модифицированный код, что может означать на несколько меньших лицензионных условий, которые вы должны соблюдать.
Обычно я бы не рекомендовал распространять предварительно скомпилированные версии вашей библиотеки внутри вашего исходного репозитория. С Sourceforge вы можете предварительно скомпилировать свою библиотеку (или любой другой «конечный продукт») для основных платформ и предложить их для загрузки.
/
|- bin - Compiled binaries go here (not submitted to source-control)
|- build - buildscripts, tools used to build your code.
|- lib - Compiled libraries go here (not submitted to source-control)
|- local - (not submitted to source control)
|- obj - Compiled object-files (not submitted to source-control)
|- msvc - Autogenerated solution files for visual studio (not submitted to source control) (if applicable)
|- scripts - Autogenerated script files (if applicable)
|- units
|- libportion
|- include - external headers for other units to see
|- src
|- guiportion
|- include
|- src
|- external
|- externallib1
|- include
|- src
build - simplified build-script calling the correct convention to your buildscripts.
README - text-file explaining your software and the layout of your source.
Это организация, которую я использую в последнее время, и она была высоко оценена всеми, в том числе. Это также упрощает разделение библиотек между собой и упрощает предоставление внутренних и внешних заголовков в библиотеках.
Edit: Добавлен "локальный" каталог.
На вашем месте я бы сначала разделил проект на собственный код и сторонние библиотеки. Может получиться следующее дерево :
/
|- GUI
|- lib
|- third parties
|- compiled targets
|- "your first library"
|- "another library"
|- ...
Не стоит размещать скомпилированные библиотеки в своем репозитории, имхо. Более гибко позволить разработчикам компилировать их на своем компьютере, но если вы хотите иметь поставляемый tarball, он должен включать предварительно скомпилированные библиотеки.