Я собираюсь открыть исходный код проекта С++ на Sourceforge. Могу ли я получить некоторые советы по организации кода?

Я собираюсь загрузить проект, над которым я работал в Sourceforge под GPL, и надеялся получить некоторые советы о том, как организовать код таким образом, который легко понять и использовать разработчиками, которые может смотреть на него, что хорошо работает с git, и то, как Sourceforge представляет вещи.

Мои проекты - это кросс-платформенное приложение на С++ и состоит из следующих элементов:

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

Какой лучший способ организовать это?

Работая над ним сам, из корня проекта я имею это вот так:
/LibPortion
/GuiPortion
/libs/ библиотеки с открытым исходным кодом
/libs/ измененные библиотеки с открытым исходным кодом
/libs/compiled/ для хранения скомпилированных библиотек, в том числе при компиляции для Windows некоторых, которые не принадлежат к библиотекам с открытым исходным кодом, таким как файлы библиотеки Cygwin

Это разумный способ организовать вещи? Соответствует ли это соглашениям и ожиданиям?

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

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

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

Ответ 1

В общем, отделите свою работу от работы третьих лиц. На самом базовом уровне ваша корневая папка может выглядеть так:

|- GUI
|- Library
|- Third-party
    |- lib
    |- source

Я разделил папку "сторонняя" на две подпапки в целях соблюдения лицензии и простоты использования. Как именно вы распространяете сторонние библиотеки, будет полностью зависеть от их лицензий. Настройте свои файлы make файлов, чтобы скомпилированные библиотеки попали в папку third-party\lib (в которой вы также разместите любые предварительно скомпилированные библиотеки). Таким образом, пользователь может загрузить предварительно скомпилированные библиотеки и игнорировать папку source или загрузить исходный код и игнорировать папку lib в зависимости от того, хотите ли они повторно построить сторонние библиотеки.

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

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

При использовании немодифицированных библиотек было бы лучше вообще не включать исходный код или двоичный файл в исходное дерево. Просто запишите в своей документации, что ваш проект зависит от библиотеки X (укажите также версию, если это важно) и укажите ссылку на домашнюю страницу проекта библиотеки/страницу/репозиторий Sourceforge. Пусть разработчик решит, хотят ли они компилировать библиотеку, загружать предварительно скомпилированную версию или, возможно, использовать версию, которую они уже установили. Это означает, что вы также не можете предположить, что библиотека или ее заголовки будут существовать в определенном каталоге относительно вашего исходного кода; вместо этого вам придется доверять пользователю, чтобы установить библиотеки, в которых компилятор может их найти. Ваш код просто предположит, что они находятся в пути поиска компилятора.

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

Как правило, я бы не рекомендовал распространять предварительно скомпилированные версии вашей библиотеки внутри исходного репозитория. С помощью Sourceforge вы можете предварительно скомпилировать свою библиотеку (или любой другой "конечный продукт" ) для основных платформ и предлагать их в качестве загрузок.

Ответ 2


/
|- 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.

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

Изменить: добавлен "локальный" каталог.

Ответ 3

Если бы я был вами, я бы отделил проект между вашим собственным кодом и библиотеками третьих сторон. Следующее дерево могло бы работать:

/
|- GUI
|- lib
|- third parties
    |- compiled targets
    |- "your first library"
    |- "another library"
    |- ...

Вы не должны размещать скомпилированные библиотеки в вашем хранилище imho. Это более гибко, чтобы разработчики могли компилировать их на своем собственном компьютере, но если вы хотите иметь готовый tarball, он должен включать в себя предварительно скомпилированные библиотеки.

Ответ 4

ИМХО, рассматривая организацию различных проектов с открытым исходным кодом, может помочь.

страница проекта vlc может быть хорошей ссылкой