Управление проектом C ++ - расположение файлов, зависимости и контроль версий

Question

Я недавно запустил новый проект на C ++ и собираюсь сделать его кроссплатформенным в срок. Раньше у меня не было большого опыта работы с проектами на C ++, поэтому первое, что меня беспокоит, это настройка макета файла Visual Studio по умолчанию. Я попытался перечитать Сеть на эту тему, но информация кажется редкой и противоречивой, поэтому я начал с чего-то простого:

build
  vc2010  // Visual C++ solution/project files
lib 
  include // Header files for third-party libs
  // All library binaries here (like .lib, .dll or .so)
src
  // My own code (including headers)
temp
  // I use this as intermediate file output directory (for Visual C++)

Затем проект Visual C ++ настраивается для вывода окончательного файла .exe в корневой каталог проекта (сборки отладки / выпуска), чтобы я мог также поместить туда свои собственные конкретные данные (например, data/ dir). Пожалуйста, обратите внимание, я намереваюсь управлять своим проектом в репозитории контроля версий исходного кода (за исключением некоторых типов, таких как .exe), и я не пишу здесь библиотеку. Итак, мои вопросы:

Существуют ли какие-либо де-факто стандарты для структурирования ваших проектов? Или они зависят от платформы и пользователя?

Как вы справляетесь с библиотечными зависимостями? Вы просто помещаете предварительно скомпилированные двоичные файлы (как в моей настройке) или используете полный исходный код библиотеки и настраиваете процесс сборки проекта, чтобы включить их в процесс. Это хорошая идея, чтобы поставить бинарные файлы под контроль версий (например, .lib / .dll в этом случае)?

Answer 1

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

Он не будет знать, что делать с файлами решений / проектов, они специфичны для Visual Studio.Так что на самом деле не имеет значения, как вы это структурируете.В любом случае вы будете делать это заново.

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

При наличии сторонних зависимостей вы можете обнаружить, что они уже установлены (или могут быть установлены) в системе, в которой вы находитесь.портирование на, и в этом случае вы можете с радостью использовать установленную версию, или вы можете зависеть от очень конкретной версии.В любом случае, предварительно скомпилированные двоичные файлы бесполезны в другой системе.

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

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

Если вы хотите создать переносимость с самого начала, это может бытьХорошая идея, чтобы настроить для двух разных систем одновременно.Вы можете сделать это, не выходя из Windows - например, попробуйте установить Code :: Blocks и собрать с MinGW, а также то, что вы уже делаете с Visual Studio.

Также помните, что многие библиотеки выестественно использовать на Windows, просто не доступны на других платформах.Система сборки будет меньше всего беспокоить вас, если вы написали приложение с графическим интерфейсом на основе API Windows, а затем хотите перенести его на OSX.

Answer 2

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

Во-первых, вы обязательно должны решить, хотите ли вызаниматься кросс-платформенной разработкой ... И я имею в виду не только несколько ОС, но и несколько компиляторов, ide (?) и стандартные библиотеки.Даже в Unix существуют рифы между Linux и BSD, некоторые говорят, что это просто проблемы с лицензированием, но код, похоже, движется в разных направлениях.

Итак, первое, что нужно сделать, это решить проблему построенияваши вещи, и вы можете просто использовать один файл, который генерирует все остальное (например, CMake, bakefile или один из других, который пытается быть лучше, чем make), или вы можете иметь один каталог сборки со многими файлами сборки, которые поддерживаются отдельно,Секунды работают хорошо, когда не так много разных платформ (и в большинстве случаев у вас будет комбинация make (или одного из его вариантов, таких как tup) и gcc или clang или [вставьте сюда другой компилятор на основе Unix], иих у вас будут Borland, Visual Studio и т. д. и т. д.

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

В-третьих, всегда есть документация, обычно она взята из технических руководств, и почти во всех технических книгах, а иногда и забытаразработчиками, но это важно, так как ваши пользователи не будут понимать ваш код, хотя хрустальный шар, и вы можете использовать что-то вроде doxygen (для C ++) и docbook / markdown / ... для остальных (яНа самом деле, пытаясь выяснить последнюю часть (нетехническую документацию), одна крутая цель - иметь документацию в репозитории, и когда вы обновляете документацию, скрипт сборки обновляет веб-сайт, и хотя используется что-то вроде подмодулей gitвсякий раз, когда кто-то проверяет или обновляет свой код из вашего хранилища кода, он также проверяет самую последнюю документацию.(Это в основном то, что Maven Doxia пытается сделать для Java, даже если с ужасным рабочим процессом)

Таким образом, в конце вы можете закончить с папками src, папкой включения (если у вас есть публичные заголовки),папка doc (с вашей документацией), папка сборки (в случае нескольких сценариев сборки) и папка ресурсов или ресурсов (если у вас есть связанные файлы, такие как изображения, текст перевода, файлы xml, файловые базы данных (например, sqlite) и т. д..).Что, если ваш ленивый тип, как я, означает большую работу, чтобы настроить проект (сделать его сборочным, тестируемым и иметь возможность создавать документацию).

Об источнике информацииСборки, которые зависят от вас, хотя некоторые инструменты стимулируют это (CMake приходит на ум), но не забудьте настроить свой репозиторий, чтобы там не оказалось ненужных файлов, либо случайно, либо потому, что некоторые неуклюжие разработчики разместили их там.Если вам нужно, просто поместите все ваши файлы сборки (например, из VC ++) в каталог, специфичный для этого файла сборки (например, vcbuild), и напишите скрипт установки, который помещает двоичные файлы и необходимые файлы, гдепользователь хочет их, и вам просто нужно настроить систему управления исходным кодом, чтобы игнорировать эти каталоги и все, что находится под ними.

Answer 3

Если вы хотите использовать Visual Studio (VC ++ можно использовать без него), то вам следует помнить о некоторых вещах.Вы можете изменить, откуда он получает свои файлы и куда их помещает, так что вы не привязаны к его структуре по умолчанию.Однако некоторые из его подчиненных инструментов имеют массу проблем с наличием разных исходных файлов с одинаковыми именами (очевидно, в разных каталогах), поэтому этого следует избегать.

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

Answer 4

Просто помните, как бы вы ни старались сделать его переносимым во время разработки в Visual Studio, он сломается при первой попытке собрать / запустить его на любой другой платформе.

Если вы хотите, чтобы проект был кроссплатформенным, я бы порекомендовал начать с по крайней мере двух платформ с самого начала (например, Windows & Linux) и часто проверять, что он собирается / работает на обеих. Я бы также предложил начать с чего-то другого, кроме Visual Studio ... не потому, что VS плохой ... он просто не идеален для настройки кроссплатформенного проекта. Мне нравится CMake и сборки вне исходного кода.

Если приложение будет иметь графический интерфейс пользователя, используйте портативную библиотеку графического интерфейса, например wxWidgets , QT и т. Д.

Палка с вещами, о которых известно, что они портативны ... boost , libxml2 , ODBC и т. Д.