Visual С++ 2008 продолжает терять настройку правила пользовательской сборки

Итак, по разным «скучным» причинам я застрял на VC++ 2008.

Теперь у меня есть пользовательское правило сборки, которое анализирует файл «.h» и создает файл .cpp.

Правило сборки работает нормально, когда я могу получить параметр в .vcproj (он отображается как элемент ‹Tool Name="my rule"/› как дочерний элемент элементов ‹FileConfiguration> для каждого элемента ‹File>).

В файле «.rule» атрибут FileExtension, который я указал, имеет значение «*.hxx», а не «*.h», поскольку я не хочу, чтобы пользовательское правило выполнялось для каждого .h, а только те, которые я хочу . Изменение расширения файлов для запуска правила на что-то другое, кроме .h, не является вариантом по причинам, которые я не могу контролировать.

Правило работает нормально, сгенерированный .cpp компилируется, все зависимости и т. д. работают, т. е. VC++ выполняет пользовательский шаг только при изменении .h и т. д.

Ручной взлом xml в .vcproj заставляет работать, проблема в том, что графический интерфейс Visual Studio продолжает возиться с настройкой инструмента и удалять его из «.vcproj». Я не определил точно, при каких условиях Visual Studio искажает настройки, поскольку они несколько случайны, но в основном, когда необходимо сохранить какие-либо изменения в проекте, это мое наблюдение.

Иногда (не всегда) я могу вручную изменить инструмент на странице свойств в графическом интерфейсе Visual Studio, и он сохранит его для активной конфигурации (например, «Отладка»), но когда я попытаюсь добавить его в другие конфигурации (например, «Выпуск " или "Все конфигурации"), графический интерфейс запутается и удалит настройку инструмента для всех конфигураций вместо того, чтобы добавить ее для другой конфигурации.

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

Мне удалось заставить аналогичные правила работать нормально, когда входной файл для настраиваемого правила имеет уникальное расширение, похоже, оно связано с входным именем, соответствующим «.h», и правилом по умолчанию для .h, а мое «. rule" не указывает соответствующий шаблон соответствия.

Обратите внимание, что эта настройка с несоответствующим шаблоном FileExtension — это то, что было рекомендовано в MSDN для VC++ 2008, поэтому я сделал это именно так.

У кого-нибудь были подобные проблемы? Любые подсказки о том, каким может быть надежное решение и/или обходной путь?

Мне просто нужно сохранить настройку в контексте того, что NOOBS может использовать графический интерфейс VS, поэтому вы не можете доверять им, чтобы они не делали «определенных вещей».


visual-c++-2008
person user6092647    schedule 21.03.2016    source источник
comment
Добро пожаловать в SO, пожалуйста, будьте немного более конкретными, когда задаете вопрос: что вы пробовали, чего вы ожидаете и т. д. См. , как спросить   -  person Nehal    schedule 21.03.2016
comment
Не уверен, как быть более конкретным, не будучи чрезмерно многословным - это уже довольно длинный вопрос. Я почти уверен, что любой, кто может ответить на этот вопрос, найдет в моем описании проблемы много деталей. Кроме того, я думаю, довольно ясно, что я пробовал разные вещи. Также, пожалуйста, уточните, почему вы не понимаете, чего я ожидаю, поскольку я чувствую, что это также совершенно ясно.   -  person user6092647    schedule 22.03.2016

Ответы (1)


arrow_upward
0
arrow_downward

Итак, после долгих поисков здесь и в любом другом месте, о котором я мог подумать, и перепробовав кучу подлых заклинаний, я все еще не получил удовольствия от фактического решения проблемы предотвращения удаления IDE настройки пользовательского инструмента сборки, когда расширение шаблон не соответствует файлу.

Таким образом, работа заключалась в том, что я изменил правило, чтобы использовать шаблон «*.h», и провел тест, чтобы увидеть, нужно ли запускать пользовательскую команду. Ниже приведен мой файл «FunkyRule.rules» на случай, если кому-то понадобится посмотреть, что я сделал:

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
   Name="Funky code generator"
   Version="8.00"
   >
   <Rules>
      <CustomBuildRule
          Name="Funky"
          DisplayName="Funky code generator"
          CommandLine="IF NOT EXIST $(InputFileName) goto :notFound &#x0D;&#x0A;
                       NeedsFunky $(InputFileName) 1>nul || goto :notFound &#x0D;&#x0A;
                       echo Generating Funky things for $(InputFileName) &#x0D;&#x0A;
                       FunkyCodeGenerator $(InputFileName) -o &quot;.\GeneratedFiles\funky_$(InputName).cpp &quot;&#x0D;&#x0A;
                       goto :done &#x0D;&#x0A;
                       :notFound &#x0D;&#x0A;
                       exit 0 &#x0D;&#x0A;
                       :done &#x0D;&#x0A;"
          Outputs=".\GeneratedFiles\funky_$(InputName).cpp"
          AdditionalDependencies="$(InputFileName)"
          FileExtensions="*.h"
          ShowOnlyRuleProperties="false"
          >
          <Properties>
          </Properties>
       </CustomBuildRule>
   </Rules>
</VisualStudioToolFile>

Этому CustomBuildRule нужны две внешние команды «NeedsFunky» и «FunkyCodeGenerator». «NeedsFunky» — это команда, которая возвращает 0, если ввод .h является допустимым вводом для «FunkyCodeGenerator», и ненулем в противном случае. «FunkyCodeGenerator» — это команда, которая делает «причудливые вещи», принимая входной .h в качестве параметра и требуя параметр -o для указания выходного файла. В этом контексте (т. е. независимо от того, что среда Visual Studio называет результирующим временным файлом .bat), у меня были некоторые проблемы с тем, чтобы оператор IF работал с использованием обычного синтаксиса «IF errorlevel», поэтому, следовательно, необычный «cmd || goto :failLabel ".

Если вы добавите этот файл правил в пользовательские правила сборки для проекта, вы автоматически получите «некоторую забавность» для всех ваших файлов «.h» :-)

person user6092647    schedule 23.03.2016