У кого какие впечатления от новомодной структуры каталогов SDK/WDK, где в include/lib есть еще один промежуточный уровень из версии? Понятно, что это сделано с целью сваливания всех наличных наборов в Program Files, когда в каждом include/lib собираются разные версии, но мне это кажется голимым извращением. Хотя бы потому, что раньше можно было в свойства проекта добавить что-нибудь вроде $(SDK)\include\um, затем менять только значение переменной (пока не поменялась структура), а теперь нужно заводить отдельную переменную для версии.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У кого какие впечатления от новомодной структуры каталогов SDK/WDK, где в include/lib есть еще один промежуточный уровень из версии? Понятно, что это сделано с целью сваливания всех наличных наборов в Program Files, когда в каждом include/lib собираются разные версии, но мне это кажется голимым извращением. Хотя бы потому, что раньше можно было в свойства проекта добавить что-нибудь вроде $(SDK)\include\um, затем менять только значение переменной (пока не поменялась структура), а теперь нужно заводить отдельную переменную для версии.
Какую проблему решаем то ?
В проекте vcxproj устанавливаем WindowsTargetPlatformVersion в нужную версию и MSBuild всё сам достанет как надо.
Если просто нужно достать самую последнюю версию SDK то можно использовать недокументированную: GetLatestSDKTargetPlatformVersion
Здравствуйте, _NN_, Вы писали:
_NN>Какую проблему решаем то ?
Подсунуть любую версию SDK/WDK любому компилятору/линкеру, который технически способен ее обработать.
_NN>В проекте vcxproj устанавливаем WindowsTargetPlatformVersion в нужную версию и MSBuild всё сам достанет как надо.
Это из серии "Да извозчики-то на что ж? Это их дело"?
Re[3]: Структура каталогов Windows SDK/WDK от 8.x до 10.x
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, _NN_, Вы писали:
_NN>>Какую проблему решаем то ?
ЕМ>Подсунуть любую версию SDK/WDK любому компилятору/линкеру, который технически способен ее обработать.
А как выбирать ? Наугад ?
Начиная с 2019 есть официальный способ брать последнюю:
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, _NN_, Вы писали:
_NN>>А как выбирать ? Наугад ?
ЕМ>Исходя из реальных потребностей конкретного проекта.
Для сборки используется MSBuild и vcxproj ?
Там просто всё настроил и проект соберётся.
ЕМ>Вы снова о шашечках, а я — об ехать.
Я проблемы не понимаю. К примеру нужен $(SDK)\include\um
Смотрим список всех переменных и видим $(UM_IncludePath) = c:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\um
Здравствуйте, _NN_, Вы писали:
_NN>Для сборки используется MSBuild и vcxproj ?
Изредка. В основном — традиционные средства VS (Build Tools) и вообще прямой вызов компилятора/линкера.
_NN>Там просто всё настроил и проект соберётся.
Я знаю.
_NN>Я проблемы не понимаю.
Это потому, что Вы, судя по всему, всегда используете стандартные способы установки, с параметрами по умолчанию, и стандартные же средства сборки, для которых достаточно лишь задать параметры.
Re[7]: Структура каталогов Windows SDK/WDK от 8.x до 10.x
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, _NN_, Вы писали:
_NN>>Для сборки используется MSBuild и vcxproj ?
ЕМ>Изредка. В основном — традиционные средства VS (Build Tools) и вообще прямой вызов компилятора/линкера.
То есть делаете работу msbuild-а вручную.
_NN>>Там просто всё настроил и проект соберётся.
ЕМ>Я знаю.
_NN>>Я проблемы не понимаю.
ЕМ>Это потому, что Вы, судя по всему, всегда используете стандартные способы установки, с параметрами по умолчанию, и стандартные же средства сборки, для которых достаточно лишь задать параметры.
По возможности конечно именно так.
И то со станлартной установкой бывают проблемы