Определение времени выполнения параметров компиляции

Question

Мне нужно иметь возможность определить во время выполнения, какие параметры компиляции использовались для создания исполняемого файла. Есть ли способ сделать это?

РЕДАКТИРОВАТЬ: Я особенно заинтересован в обнаружении настроек оптимизации. Причина в том, что я пишу коммерческое программное обеспечение, которое должно работать как можно быстрее. Пока я просто модифицирую и тестирую систему, я не делаю все оптимизации, потому что это занимает слишком много времени. Но я беспокоюсь, что могу случайно зайти и выпустить неоптимизированную версию программы. Я хотел бы, чтобы при запуске программа показала мне визуальное предупреждение: «Это медленная версия - не выпускать».

РЕДАКТИРОВАТЬ: Может быть, я мог бы написать небольшую утилиту для запуска в качестве шага перед сборкой? Командная строка хранится где-то в файле? Если это так, то я мог бы извлечь его, а затем записать в какой-нибудь включаемый файл в виде строки и эй presto!

РЕДАКТИРОВАТЬ: Мой выбор не между отладкой и выпуском. Отладка слишком медленная - я оставляю это строго для отладки. Мой повседневный выбор - между оптимизированным и сверхоптимизированным (включая компиляцию времени медленной компиляции или даже оптимизацию по профилю).

РЕДАКТИРОВАТЬ: Я часто вносить изменения в сложный процесс компиляции, различные библиотеки, разные предопределенные макросы, разные исходные файлы и т. Д. Кажется неуклюжим, чтобы поддерживать несколько, почти идентичные файлы проекта, отличающиеся только в паре флагов оптимизации. Я бы предпочел просто переключить пару флагов в одном проекте и заново скомпилировать. Я просто хочу, чтобы исполняемый файл самопроверял, как он был создан.

РЕДАКТИРОВАТЬ: IIRC есть некоторый способ попросить визуальную студию создать make-файл. Могу ли я попросить Visual Studio создать этот make-файл для меня как шаг перед сборкой?

Answer 1

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

Итак, настройте вашу систему сборки так, чтобы она использовала что-то вроде DEBUG_SET для отладки своих отладочных сборок и т. Д.

---

Обращаясь ко второму «РЕДАКТИРОВАТЬ», да, командная строка для ваших инструментов предварительной и последующей сборки помещается в файл vcproj проекта. Это файл XML, и вы должны найти его в теге Configurations-> Tool с атрибутом имени, похожим на «VCPreBuildEventTool». Попробуйте добавить один с графическим интерфейсом, а затем открыть файл в текстовом редакторе, и вы должны увидеть.

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

Answer 2

Я думаю, вы могли бы поступить неправильно ...

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

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

Чтобы добавить дополнительные конфигурации, используйте страницу Build-> Configuration Manager. Там вы будете использовать Debug и Release по умолчанию, и вы можете создать свой собственный «Super Release» или как вы хотите его называть.

Answer 3

Создайте несколько конфигураций для вашего проекта, например, Debug, Release & Production. Измените имена выходных двоичных файлов для каждой конфигурации, чтобы они совпадали в разных конфигурациях. Например, MyApp_d.exe, MyDll_d.dll для отладки, MyApp_r.exe, MyDll_r.dll для выпуска и MyApp.exe & MyDll.dll для производства. Это поможет сохранить все различные варианты без необходимости добавлять код (который будет медленным и ломким), который будет определять во время выполнения, какой вариант работает, и затем выполнять какое-то волшебство.

Answer 4

Попытка ответить на мой собственный вопрос ...

Если я поищу в справочной системе Visual Studio «предопределенные макросы», я получу страницу со списком различных макросов, которые определены в соответствии с различными параметрами компиляции. Это далеко не полный ответ, но это может быть лучшее, что я получу.

Answer 5

Можно ли сохранить параметры компиляции (или полную командную строку, если она есть) в текстовом файле при вызове сборки и проверке отправки этого файла вместе с исполняемым файлом?

[Это, конечно, не элегантно, но просто хотел проверить.]

Answer 6

Чтобы сделать это правильно, вам нужно будет создать дополнительную конфигурацию, называемую «SuperOptimised».Теперь у вас есть стандартные конфигурации («Debug» и «Release») и третий «SuperOptimised».Проблема заключается в том, что это значительно усложняет управление конфигурацией проекта. Чтобы изменить общий параметр между тремя конфигурациями, необходимо внести это изменение в трех местах.

Решение этой проблемы заключается в использовании«Листы свойств» (файлы «.vsprops») и вкладка «Диспетчер свойств».Вы можете создать таблицу свойств, которая является общей для всех трех конфигураций, и специальные таблицы для Release, Debug и SuperOptimised.Объедините общие настройки с конкретными настройками (используя наследование свойств) для управления конфигурациями - вкладка «Диспетчер свойств» позволяет вам сделать это.Вы можете изменить файлы «.vsprops», чтобы изменить общие настройки для разных конфигураций без изменения самих конфигураций.

Подробнее о листах свойств здесь:

http://msdn.microsoft.com/en-us/library/a4xbdz1e(VS.80).aspx

Наконецесли вы хотите проверить, какая конфигурация была собрана во время выполнения, используйте препроцессор, чтобы определить значение макроса в файле «SuperOptimised» .vsprops, скажем «SUPEROPTIMISED».Затем вы можете проверить, есть ли у вас правильная сборка, с помощью:

#ifndef SUPEROPTIMISED
    // Warn the user that this is not a shipping build
#endif

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

Answer 7

Несколько компиляторов устанавливают разные определения при компиляции. Это вы можете использовать в своей программе. (он не обнаруживает во время выполнения, он просто «запекается» в вашей программе во время компиляции).

Для GCC они показаны здесь . Они также содержат уровень оптимизации.

Здесь - список для Visual Studio. Однако я не думаю, что он содержит уровень оптимизации, возможно, у него есть другая информация, которую вы можете использовать.

Поскольку это наиболее распространенный способ передачи информации от компилятора в исполняемый файл. Я не думаю, что это возможно для визуальной студии.

---

Answer 8

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

Если это так, то следующие параметры:

1. Создайте .exe другое имя для каждой конфигурации, например, App_d, App_super_optimized и т. Д.
2. Добавить различные определения символов в каждую конфигурацию, которые можно проверить как #defined при запуске
3. Возможно, в сочетании с 2. make all, кроме вашей сборки выпуска, должен присутствовать некоторый файл, который вы не распространяете. Таким образом, ваши пользователи не смогут запустить медленную версию, даже если вы выпустите ее случайно.

Answer 9

У меня есть хитрость для проверки того, что я не выпускаю отладочные версии моих программ. Я сравниваю размер исполняемых файлов и библиотек DLL с размерами тех же двоичных файлов последнего выпуска. Они должны быть одинакового, обычно слегка увеличенного размера. Если у меня есть Debug-версия файла, размер будет x3 или x4 этого размера версии Release.

Answer 10

Visual Studio 2008 уже настроил это для вас. Когда вы создаете новый проект, он настраивает для вас две конфигурации сборки: Debug и Release. Вы можете переключаться между этими конфигурациями с помощью панели управления.

Отладка имеет настройки, настроенные для отладки, в частности оптимизация отключена.

Релиз имеет настройки, адаптированные для релиза, в частности, включена оптимизация.

Макрос препроцессора DEBUG определен только в конфигурации отладки, поэтому вы можете легко сделать что-то вроде:

#ifdef DEBUG
::MessageBox("You are using the debug version", "Warning - Slow", MB_OK);
#endif

Обратите внимание, что эти конфигурации помещают свои выходные данные в разные папки, поэтому их легко отличить друг от друга.