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

Question

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

EDIT: Я особенно заинтересован в определении параметров оптимизации. Причина в том, что я пишу коммерческое программное обеспечение, которое должно работать как можно быстрее. Хотя я просто модифицирую и тестирую систему, я не делаю все оптимизации, потому что это занимает слишком много времени. Но я волнуюсь, что я могу случайно выйти и опубликовать неоптимизированную версию программы. Я бы хотел, чтобы программа дала мне визуальное предупреждение при запуске, сказав что-то вроде «Это медленная версия - не выпускайте».

EDIT: Возможно, я мог бы написать небольшую утилиту для запуска в качестве этапа предварительной сборки? Где-то в каком-то файле хранится ли в командной строке? Если это так, я мог бы извлечь его, а затем записать его в какой-то файл include как строку и hey presto!

EDIT: Мой выбор не между отладкой и выпуском. Отладка слишком медленная - я резервирую это строго для отладки. Мой ежедневный выбор - между оптимизированными и супер-оптимизированными (включая компиляцию с медленным компиляцией времени или даже оптимизацию с учетом профиля).

EDIT: Я часто вносить изменения в сложный процесс компиляции, различные библиотеки, различные предопределенные макросы, различные исходные файлы и т.д. кажется неуклюжим, чтобы поддерживать несколько, почти идентичные файлы проекта, отличающиеся только в пара оптимизационных флагов. Я бы предпочел просто, как-то и когда-то, переключить пару флагов в один проект и перекомпилировать. Я просто хочу, чтобы исполняемый файл самостоятельно тестировал, как он был создан.

EDIT: IIRC есть способ попросить визуальную студию создать файл makefile. Могу ли я попросить визуальную студию создать этот make-файл для меня как шаг предварительной сборки?

Answer 1

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

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

Более подробную информацию о Sheets собственности здесь:

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 2

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

Так настроить вашу систему сборки использовать что-то вроде DEBUG_SET для отладки его отладки строит, и т.д.

---

Решение второй «EDIT», да в командной строке для prebuild и postbuild инструменты помещаются в файл проекта vcproj. Это XML-файл, и вы должны найти его под тегом Configurations-> Tool с атрибутом name что-то вроде «VCPreBuildEventTool». Попробуйте добавить один с графическим интерфейсом, а затем открыть файл в текстовом редакторе, и вы должны увидеть.

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

---

Answer 7

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

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

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

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

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

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

Если да, то следующие несколько вариантов:

1. Постройте .exe другое имя для каждой конфигурации, например App_d, App_super_optimized и т.д.
2. Добавить другое определение символа в каждой конфигурации, которые могут быть проверены как #defined at startup
3. Возможно, в сочетании с 2. make все, кроме вашей сборки релиза, требует наличия некоторого файла, который вы не распространяете. Таким образом, ваши пользователи НЕ МОГУТ запускать медленную версию, даже если вы ее выпустите случайно.