Как обычно настраиваются среды MS Visual C ++?

Question

Я родом из Java, и магазин, в котором я сейчас работаю, отказывается использовать что-либо, кроме MS VC ++, для создания своего унаследованного проекта. Похоже, что они не используют какие-либо стандарты для настройки своей среды сборки, кроме как просто для ее построения с использованием VS2005 и нажатия кнопки компиляции.

Мне было интересно, есть ли что-нибудь ближе к тому, что было в Java, например:

• Инструмент для сборки, такой как ANT или Maven
• Структура каталогов, которая имеет смысл, содержащая
  • src - Место для всех моих исходных файлов .c / .cpp / .h
  • lib - место для любых библиотек, которые могут использоваться в проекте (.dll, .lib)
  • dist - Место для исполняемого файла вывода / распространения проекта
  • ресурсы - место для любых изображений / звуков / текстовых файлов, которые могут быть включены в проект.
  • build.xml - своего рода файл сборки (я думаю, что-то вроде ./configure или MAKEFILE)

Или я слишком много спрашиваю из среды сборки C ++? Всегда ли это так хаотично, как это делают люди в моем магазине? Мне действительно трудно поверить, что, учитывая успех многих проектов C ++ в Интернете.

Answer 1

Похоже, у вас благие намерения - выходя из мира, не принадлежащего MSVC, я вижу ваши очки.

Если бы я был на вашем месте, я бы определенно создал командную строку / автоматизированный сервер сборки / сборки.

Вы можете использовать MSBuild для этого - и у Хадсона есть плагин для этого. У меня обычно есть каталог "Build" рядом с корнем проектов, который содержит сценарии / etc, которые будут вызывать соответствующие файлы MSBuild / .sln.

"Makefiles" для Visual Studio - это файлы .sln и .vcproj. Вы можете вызвать их с помощью msbuild из командной строки. Вы также можете экспортировать make-файл (я думаю, что это еще вариант) из среды IDE, которую вы можете запустить. Я не рекомендую идти по этому пути, кроме как попробовать его и посмотреть, что получится - поскольку это то, с чем вы знакомы.

Как файлы vcproj, так и файлы sln удобочитаемы для человека - пройдите их - это даст вам некоторую полезную информацию.

Я бы также согласился, что наличие каталога для распространения - это хорошо - для сборки установщика / etc после сборки. Скопируйте туда все необходимые двоичные файлы - либо в шагах после сборки, либо в другом скрипте / и т.д.

Дайте нам знать, что вы в конечном итоге делаете.

У меня есть еще один совет: ОБНОВЛЕНИЕ до VC / Dev studio 2008 или 2010 года. КАК МОЖНО СКОРЕЕ

Answer 2

MSVC не навязывает вам какую-либо структуру каталогов. Существуют некоторые значения по умолчанию, как указано выше для каталогов Debug и Release, например, но даже они могут быть переопределены для каждого проекта. Используйте любую структуру каталогов, которая имеет для вас смысл.

Visual Studio предоставляет поддержку командной строки, если вы не хотите использовать IDE. См. Эта статья MSDN для получения дополнительной информации.

Answer 3

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

В нашем большом решении VS мы используем, например, obj/$(ProjectName)/$(ConfigurationName) в качестве промежуточного каталога и bin/$(ConfigurationName) в качестве выходного каталога во всех подпроектах.

Все эти вещи должны выполняться пользователем, и, похоже, ни одна рекомендация / передовой опыт не выработались.

Answer 4

Стандартизированный материал:

• Инструмент сборки: Visual Studio (дополнительный продукт не требуется)
• Файл сборки: *.sln / *.vcproj (*.vbproj для Visual Basic и т. Д.)
• Структура каталогов: каталоги «Debug» и «Release» для выходных двоичных файлов.

Все остальное не столько "хаотично", сколько "на самом деле не имеет значения". «Хаотично» предполагает, что оно постоянно меняется, но на самом деле вы просто выбираете один для проекта и придерживаетесь его. Компании могут иметь внутренние стандарты для разных проектов. Просто не имеет значения, стоит ли заниматься стандартизацией в разных компаниях. С ++ в любом случае является сложным языком; Любой, имеющий достаточный IQ для чтения C ++, может иметь дело с разумными вариациями. Разница между \lib\ и \Library\ не остановит их.