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

Question

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

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

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

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

Во время работы над ней сам, от корня проекта у меня есть это так:
/LibPortion
/GuiPortion
/LIBS/библиотеки с открытым исходным кодом
/ЛИЭС/модифицирована с открытым исходным кодом библиотеки
/ЛИЭС/скомпилированный/для хранения скомпилированных библиотек, в том числе при компиляции для Windows, некоторые из которых не из библиотек с открытым исходным кодом, таких как файлы библиотеки Cygwin.

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Редактировать: Добавлен «местный» каталог.

Answer 4

Имхо смотрит на организацию различных проектов с открытым исходным кодом.

vlc project page может быть хорошим справочник