Visual Studio (C ++) - каков наилучший способ настройки каталогов? - PullRequest
6 голосов
/ 06 ноября 2011

(я использую VS 2010, но большая часть информации актуальна, по крайней мере, до VS 2003, возможно, с небольшими различиями в организации / расположении меню конфигурации сборки \ GUI)

При настройке сборки проекта существует раздел с именем "Каталоги VC ++" , который содержит 6 меток.2 из них:

  1. Библиотечные каталоги
  2. Включить каталоги

Кроме того, если выперейдите к 'C / C ++' -> «Дополнительные каталоги включения» , вы можете указать дополнительные каталоги, которые AFAIK (из описаний этих каталогов в справке MSDN и VS) идентичны «Включить каталоги» (хотя между ними, вероятно, есть какой-то порядок поиска).Аналогично, если вы перейдете на 'Linker' -> 'Дополнительные каталоги библиотек' , вы можете указать дополнительные пути для библиотек для связи с проектом (здесь более точное описание - "Позволяет пользователю переопределять средупуть к библиотеке », поэтому эти пути ищутся быстрее).

Мой вопрос-

есть ли причина использовать один (из путей) над другим?какова лучшая практика?

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

Ответы [ 2 ]

4 голосов
/ 06 ноября 2011

Давайте сначала рассмотрим только пути.

В документации Microsoft указано, что компилятор ищет каталоги в следующем порядке:

  1. Каталоги, содержащие исходный файл.

  2. Каталоги, указанные с параметром /I, в том порядке, в котором CL их встречает.

  3. Каталоги, указанные в переменной среды INCLUDE.

Теперь, ["Каталоги VC ++" & rarr; «Включить каталоги»] задокументировано как соответствующее переменной INCLUDE. Т.е. эти каталоги ищутся последними. Согласно документации.

И ["C / C ++" & rarr; "Общий" & rarr; «Дополнительные каталоги включения»] задокументированы как соответствующие опции /I. Т.е. эти каталоги ищутся первыми. Согласно документации.

Поскольку существует лучшая практика, вероятно, это

  • оставить открытым возможность переопределения включений, а

  • , чтобы минимизировать длину командной строки вызова компилятора (чтобы не подчеркивать плохую Windows - насколько я помню, было / есть ограничение 8 КБ или около того).

То есть, используйте ["Каталоги VC ++" & rarr; «Включить каталоги»] по умолчанию.


Полный набор соответствий переменных среды:

  • ["Каталоги VC ++" & rarr; "Исполняемые каталоги"] & rarr; PATH

  • ["Каталоги VC ++" & rarr; «Включить каталоги»] & rarr; INCLUDE

  • ["Каталоги VC ++" & rarr; "Справочные каталоги"] & rarr; LIBPATH (для #using)

  • ["Каталоги VC ++" & rarr; "Библиотечные каталоги"] & rarr; LIB


Как я узнал об этом?

Просто нажав на GUI и нажав F1 для помощи. : -)

Это всегда хорошая идея для RTFM.

Приветствия & hth.,

0 голосов
/ 06 ноября 2011

По умолчанию Visual Studio помещает следующие пути в переменную INCLUDE ( Каталоги VC ++ -> Включить каталоги ):

  • путь к заголовкам Microsoft Visual C ++: $(VCInstallDir)include
  • путь к заголовкам MFC (для проектов MFC): $(VCInstallDir)atlmfc\include
  • путь к заголовкам Windows SDK: $(WindowsSdkDir)include;$(FrameworkSDKDir)\include

Они предварительно настроены и просто оставляют их там, где они есть. Если ваш проект зависит от некоторых дополнительных компонентов / каркасов, добавьте пути к их заголовкам в C / C ++ -> Общие -> Дополнительные каталоги включения (/I переключатель компилятора). В этом случае используйте угловые скобки с вашими #include утверждениями.

То же самое для библиотек - оставьте значения по умолчанию Visual Studio и пути к библиотекам из дополнительных компонентов / каркасов, добавьте к Linker -> Дополнительные каталоги библиотек .

...