[MSVS] макросы для имени получающегося бинарного файла
Чем не устраивает простое решение: в postbuild-event-е переименовывать результирующий файл в нужное имя?
на тему использования post buildevent-ов - свежая мысль 
про такое решение не ясно вот что:
как сгенерировать нужное имя?
приходит на ум написать скрипт, и ему на вход давать все параметры, определяющие имя файла, чтоб он там уж сам разбирался, куда переименовывать,
но как-то громоздко, или я чего-то недопонял
все же, хотелось бы научится задавать правильный Output File.
к переименовыванию имеются следующие препятствия:
1) хочется использовать полученные на его основе макросы TargetName, TargetFileName, TargetPath.
Сейчас они используются для генерации pdb и lib файлов (Generate Program Database file = $(TargetDir)$(TargetName).pdb Import Library = ..\Lib\$(TargetName).lib )
2) бывают уже определенные post-build event-ы, вроде как скопировать полученный экзешник в каталог с тестирующим приложением - тут тоже удобнее юзать $(TargetPath)
3) подозреваю, что clean для переименованного post-buil event-a не сработает.
4) если файл переименовывать, а не копировать, то тогда каждый раз проект будет перелинковываться, а в debug конфигурации хочется пользоваться Incremental Link
5) не будет ли проблем дебаггеру, при отладке солюшена с несколькими библиотеками: поймет ли дебаггер , что загруженная dll имеет какое-то отношение к проекту, открытому в IDE? или там в pdb файлах информации хватит?
про такое решение не ясно вот что:
как сгенерировать нужное имя?
приходит на ум написать скрипт, и ему на вход давать все параметры, определяющие имя файла, чтоб он там уж сам разбирался, куда переименовывать,
но как-то громоздко, или я чего-то недопонял
все же, хотелось бы научится задавать правильный Output File.
к переименовыванию имеются следующие препятствия:
1) хочется использовать полученные на его основе макросы TargetName, TargetFileName, TargetPath.
Сейчас они используются для генерации pdb и lib файлов (Generate Program Database file = $(TargetDir)$(TargetName).pdb Import Library = ..\Lib\$(TargetName).lib )
2) бывают уже определенные post-build event-ы, вроде как скопировать полученный экзешник в каталог с тестирующим приложением - тут тоже удобнее юзать $(TargetPath)
3) подозреваю, что clean для переименованного post-buil event-a не сработает.
4) если файл переименовывать, а не копировать, то тогда каждый раз проект будет перелинковываться, а в debug конфигурации хочется пользоваться Incremental Link
5) не будет ли проблем дебаггеру, при отладке солюшена с несколькими библиотеками: поймет ли дебаггер , что загруженная dll имеет какое-то отношение к проекту, открытому в IDE? или там в pdb файлах информации хватит?
дебаггеру, при отладке солюшена с несколькими библиотеками: поймет ли дебаггер , что загруженная dll имеет какое-то отношениепоймет.
Можно сделать просто много переменных окружения, но они будут глобальными, что не очень хорошо.
Или покапать VCLinkerTool.OutputFile
и все-таки не ясно, как сгенерировать имя файла, в которое надо будет переименовать бинарник
плодить переменные окружения для каждого проекта не очень хочется, так как их будет лениво заводить для компиляции проекта на новом компьютере
плодить переменные окружения для каждого проекта не очень хочется, так как их будет лениво заводить для компиляции проекта на новом компьютере
Так вроде ж в 2005 уже вовсю используется MSBuild. Открой файлег .sln (или который отдельно для проекта там вменяемая хмлка, которую можно совершенно замечательно подправлять программным образом снаружи. Или, если как следует разрюхать мсбилд, то, возможно, у него что-нить такое условно-скриптовенькое есть отдельно.
Оставить комментарий
trobak
Задача: в MS Visual Studio (скажем, 2005, хотя наверное, не важно) хочется "гибко" задавать имя получающегося бинарного файлы (Project Properties\Configuration properites\Linker\General\Output file).Имя файла зависит от нескольких параметров: конфигурация (помимо Debug и Release есть еще несколько платформы (Win32/x64 номера версии.
Сейчас вручную для каждого набора конфигурация/платформа стоит что-то вроде $(OutDir)\$(ProjectName)2.1.3w32D.dll (2.1.3- версия, w32 - платформа, D - дебажная конфигурация).
Очевидное неудобство в том, что при смене номера версии нужно лезть в каждую пару (конфигурация, платформа) для каждого проекта. Библиотек и экзешников несколько штук, и они разбросаны по нескольким Solution-ам - редактировать каждый очень утомительно.
Хотелось бы иметь что-то аналогичное встроенным макросам, но определяемые вручную (например, ProjectName сильно облегчает жизнь - можно мультиселектом править сразу все проекты, пусть и в фиксированной конфигурации). Скажем, для конфигурации определить свои VerSuffix, ConfSuffix, PlatformSufix и имя файла определять как $(OutDir)\$(ProjectName)$(VerSufix)$(PlatfSuffix)$(ConfSuffix).dll.
Можно ли что-то подобное сделать и как?