Visual Studio С++ включает максимальную длину строки

Я пытаюсь скомпилировать Qt в Windows, и у меня возникла интересная проблема С#includes ошибкой с ошибкой в том, что включенный файл не существует ( "Нет такого файла или каталога" ). Однако файл существует. Файлы, делающие включение, представляют собой автоматически сгенерированные файлы "moc" (сделанные Qt), которые содержат следующие элементы:

#include "../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h"

Строка в том числе содержит 127 символов. Существует много файлов "moc", созданных и скомпилированных в сборке, но только те, у которых очень длинная длина (127 + символов), терпят неудачу.

Эти файлы, похоже, сидят в системе UNIX и распространяются через Samba на Windows. Я смог обойти эту проблему, создав символическую ссылку и заменив "qt-везде-opensource-src-4.8.2" на "qt-4.8.2" в затронутых файлах. В результате:

#include "../../../../../../../../qt-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h"

имеет длину всего 102 символа и отлично работает.

Я искал вокруг и не мог найти никакой ссылки на это. Я также не мог реплицировать проблему за пределами этой сборки Qt (просто делая произвольно длинные имена файлов и пытаясь их включить). Таким образом, возможно, что как-то make файлы nmake, которые создает Qt, делают что-то, когда они запускают cl, что в какой-то мере заставляет его отклонять long.

Есть ли у кого-нибудь дополнительная информация об этом?

Ответ 1

Так как это используется для поиска включенного файла, я склонен полагать, что он связан с ограничениями на пути к файлу ОС.

Возможно, реализация препроцессора каким-то образом ограничивает его, но это будет специфично для каждого компилятора.

Ответ 2

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

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

Ответ 3

Может существовать ограничение, установленное платформой .NET, но пока не найдено точной строки.

Вот несколько интересных ссылок на это: социальный msdn и блог MSDN.

Ответ 4

Я столкнулся с той же проблемой при создании проектов с использованием GCC на окнах. Проблема, похоже, связана с тем, как собирается Путь,

../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

становится

c:/some/working/structure/that_is/at_least/as_deep/as_the_up/levels/are/../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

(пример может быть не для масштабирования, я не считал символы...)
На этом этапе обработка пути ломается из-за слишком большой длины. В нашем случае, вынуждая компилятор использовать контрактную версию,

c:/some/qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

заставит проблему уйти.
MSDN содержит некоторые намеки на проблему в http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963 (v = vs .85).aspx
Обратите внимание, что альтернативный, более длинный поддерживающий формат пути, \? \, Похоже, не поддерживает относительные пути.

Быстрое исправление. Не используйте относительные пути такой глубины.

Ответ 5

Вы должны просто добавить путь, который вы указываете к параметрам компилятора, а не использовать что-то, что ужасно.

Ответ 6

Выбор вкладки 'project' и снятие флажка 'Shadow build' решили мою проблему.

Ответ 7

Недавно я столкнулся с такой же проблемой при создании qt на окнах с помощью msys и mingw. Системе сборки не удалось найти заголовочный файл, включенный через следующий относительный путь:

"../../../../../../../кварта-всюду с открытым исходным кодом-Src-5.0.1/qtbase/SRC/platformsupport/fontdatabases/основные/qbasicfontdatabase_p.h"

Но файл присутствовал, и путь был правильным.

Я создал аналогичную файловую структуру за пределами исходного дерева qt и смог воспроизвести проблему с помощью g++ из командной строки.

Я немного потрудился, уменьшив количество имен файлов по одному. Пять символов и ошибки исчезли. g++ неожиданно обнаружил файл.

Он работал, когда общие символы в include-заявлении были равны 120. Это всего лишь количественный показатель, чтобы дать приблизительное представление о том, что может быть пределом под капотом. Это может быть иначе для разных версий компилятора. Я не думаю, что ОС имеет какую-то роль в его определении. Это узкое место больше связано с предварительным процессором.