Если я использую внешний make-файл для построения решения в Visual Studio 2013, последний вставляет префикс «EXEC» в каждую строку ошибки, с которой встречается в выходных данных, перед помещением его в окно вывода. В результате нажатие на строки ошибок не приводит к переходу к исходному файлу, потому что другая часть Visual Studio теперь воспринимает «EXEC» как часть имени файла и, конечно, не может найти такой файл, потому что есть нет файла, начинающегося с ‘EXEC:’.
Вы можете легко проверить это. Создайте проект makefile, в настройках проекта в «Build Command Line» введите
echo filename.cpp(76,41) error : 'xxx' was not declared in this scope
Затем попробуйте построить проект. Вы увидите это в окне вывода:
EXEC : filename.cpp(76,41) error : 'xxx' was not declared in this scope
Есть ли способ избавиться от «EXEC:» в окне вывода?
ПРИМЕЧАНИЕ: этот ответ неверен — я не удаляю его (по крайней мере, на данный момент) здесь, потому что прикрепленные комментарии привели меня к тому, что я считаю более правильным ответом, который я разместил отдельно.
Похоже, ваша проблема вызвана характером ':'
находясь в командной строке.
Я не уверен, почему этот символ вызывает некоторую специальную обработку VS, и я не уверен, есть ли другие символы, которые будут вызывать подобное поведение. Но в вашем конкретном примере:
echo filename.cpp(76,41) error : 'xxx' was not declared in this scope
если вы удалите ':'
персонаж:
echo filename.cpp(76,41) error 'xxx' was not declared in this scope
окно Build Output показывает это:
1>------ Rebuild All started: Project: makefile-project, Configuration: Debug Win32 ------
1> filename.cpp(76,41) error 'xxx' was not declared in this scope
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Один из способов избавиться от проблемного символа в конфигурации проекта make-файла VS — это поместить вашу команду в командный файл или файл nmake, а проект make-файла VS вызовет файл batch / nmake более простой командой.
Обновить:
Эта проблема, кажется, не возникает с любой команда, которая содержит ':'
персонаж. Например, следующие команды вызывают EXEC
быть подготовленным:
echo error :
c:\util\unxutils\usr\local\wbin\echo error :
Но следующие не делают:
echoargs error :
echo :
(c:\util\unxutils\usr\local\wbin\echo
а также echoargs
являются .exe
файлы, которые повторяют их аргументы)
Таким образом, триггер, кажется, является комбинацией echo
как команда и error :
в качестве аргументов. Я предполагаю, что могут быть и другие триггеры, но чье-либо предположение так же хорошо, как и мое.
Я думаю, что я получил достаточно хорошее, хотя и неполное, представление о том, что происходит, чтобы быть полезным.
Как вы упомянули в комментариях к моему предыдущему вводящему в заблуждение ответу, проблема не в используемой командной строке, а в том, что VS проверяет вывод и добавляет EXEC
префикс в определенных конкретных случаях.
Если выходная строка содержит последовательность, которая выглядит как "error :"
или же "warning :"
— поля в строке вывода, которые заставили бы VS думать, что строка вывода является диагностической, VS будет предварять строку вывода с EXEC
если еще нет ':'
персонаж предшествующий это поле.
Например, следующая строка будет иметь префикс EXEC :
:
filename error :
и этот не будет:
filename: error :
Кажется, что VS хочет убедиться, что есть поле, указывающее диагностику, что есть что-то похожее на поле имени файла (с полями, разделенными ':'
персонажи.
Таким образом, суть в том, что когда вы создаете диагностический вывод (или переформатируете вывод в VS-совместимый формат), убедитесь, что он по крайней мере соответствует общему формату:
filename : error/warning code :
сопровождаемый тем, что кажется произвольным текстом (я не уверен, если последующий ':'
персонажи значимы).
Первые два ':'
символы — это то, что кажется важным:
':'
':'