Microsoft Visual Studio 2010 не помещает инструменты сборки в PATH для чистой цели?

Я настроил Microsoft Visual Studio для использования типа конфигурации Makefile и написал makefile для сборки моего проекта с помощью инструментов Microsoft. В разделе NMake конфигурации проекта я установил командную строку сборки build.bat, которая представляет собой файл, который просто вызывает nmake с моим makefile в качестве аргумента командной строки, например:

nmake /nologo /f makefile.x86.winnt.msvc2010

Это прекрасно работает.

Для очистки я прописал в make-файле цель, которая удаляет все артефакты сборки. Это выглядит так:

#... the rest of the makefile
clean:
    @erase /f /q $(OBJS) $(OUT) $(MAPFILE) $(PDBFILE)
    @echo + clean

Поэтому я установил командную строку clean как вызов nmake с clean в качестве аргумента. Нравится:

nmake /nologo /f makefile.x86.winnt.msvc2010 clean

Я поместил этот текст в clean.bat и установил его как «Чистую командную строку», но это не работает, потому что вызывающая оболочка не может найти nmake. Я проверил путь во время вызова очистки, и MSVS не включает инструменты сборки в путь (включая nmake) для очистки. (Обратите внимание, что выполнение приведенной выше команды nmake выполняется успешно из оболочки, для которой в PATH указана команда nmake).

Как я могу заставить MSVS включать инструменты сборки в PATH, чтобы я мог вызывать nmake в чистой командной строке? Или есть лучшее решение?


person Max DeLiso    schedule 22.10.2012    source источник
comment
Клянусь, лучшее решение — не разрабатывать на Windows! У меня были похожие проблемы весь день с VS2010.   -  person Dan    schedule 06.11.2012
comment
@Dan Я делаю большую часть своей разработки из Linux, но проект кроссплатформенный, и клиент хочет сборку для Windows. Иначе я бы не заморачивался.   -  person Max DeLiso    schedule 06.11.2012
comment
Я в таком же затруднительном положении. Попытка создать программное обеспечение с открытым исходным кодом для Windows чертовски смешно! Я бы использовал Cygwin, если бы мог, но, к сожалению, это не вариант :( Я потратил так много времени на что-то, что представляет собой одну строку apt-get в Ubuntu.   -  person Dan    schedule 06.11.2012
comment
Управление пакетами — одна из самых важных задач, с которыми Linux справляется намного лучше, чем Windoze. разглагольствует о преимуществах FOSS. Windows 8 гораздо более негостеприимна, чем предыдущие воплощения. темные дни.   -  person Max DeLiso    schedule 06.11.2012
comment
Я держу пальцы скрещенными за то, что 1) нам не нужно поддерживать пользователей на Win8, 2) если мы это сделаем, я могу продолжить сборку на Win7, и полученная программа будет установлена ​​/ запущена на Win8. Это одна вещь, которую MS, кажется, делает лучше, чем Linux - обратная и прямая бинарная совместимость. Конечно, в Linux это не очень нужно...   -  person Dan    schedule 06.11.2012


Ответы (3)


Цитата из ознакомления с Visual Studio Express:

<сильный>2. Известные проблемы

2.4. Проблемы с продуктом

2.4.1. Общие вопросы (продукт)

2.4.1.14. Чистое решение не работает для типа конфигурации: Makefile (2010 RC)

Выполнение «Чистого решения» в решении nmake сообщает о следующей ошибке:

1>------ Clean started: Project: makefiletest, Configuration: Debug Win32 ------
1>  'nmake' is not recognized as an internal or external command,
1>  operable program or batch file.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(33,5):
  error MSB3073: The command "nmake /?" exited with code 9009.
================= Clean: 0 succeeded, 1 failed, 0 skipped ==========

Чтобы решить эту проблему:

  1. Откройте окно командной строки Visual Studio.
  2. Откройте Devenv, набрав devenv /useenv.
  3. Теперь «Чистое решение» должно работать.

Or:

Передайте пакетный файл команде очистки. В пакетном файле настройте PATH для инструмента nmake, а также для другой среды сборки.

person Dan    schedule 06.11.2012
comment
Да и в Профессиональной версии та же проблема! - person Dan; 06.11.2012
comment
И я пытаюсь уйти, используя NodeJS и PhantomJS, чтобы обнаружить, что эта хрень все еще нужна для работы! Время для Ubuntu и VMWare для того дерьма Windows, которое я застрял, чтобы использовать. - person Shane; 23.02.2014

Конечно, вы правы, MSVC никогда не размещает свои инструменты сборки в пути! Таким образом, у вас есть два варианта здесь:

  • Запустите пакетный файл из командной строки VisualStudio.

  • Добавьте %ProgramFiles%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat в начало вашего пакетного файла, чтобы добавить требуемый путь к PATH.

person BigBoss    schedule 22.10.2012
comment
Второй из них сработал для меня ... когда я не смог скомпилировать после установки Windows 8.1, я проверил, что уже сделал это, а затем заметил, что я перепутал оператор пути в моей системной переменной окружения PATH =, но просто не не пробовал сборку с тех пор, как до обновления. Спасибо! - person George D Girton; 18.10.2013

Я думаю, что лучшим решением будет добавить set PATH=$(VSInstallDir)\BC\bin;%PATH% в начало вашего командного файла.

Это должно защитить сборку в будущем, если вы в будущем обновитесь до VS2012 (или более поздней версии).

person bfulgham    schedule 24.01.2013
comment
проблема в том, что оболочки, созданные Visual Studio, не имеют должным образом инициализированных сред, поэтому, когда VS переходит к запуску однострочной команды оболочки для вызова управляемой извне сборки с использованием nmake (вариант Microsoft gmake), он не может найти исполняемый файл nmake и сборка не работает. ограничение, состоящее в том, что команда должна быть длиной в одну строку, предотвращает мутацию среды И выполнение скрипта, насколько мне известно. также есть другие переменные, которые необходимо установить для запуска сборок. Ответ Дэна — единственно возможное решение, поскольку оно переопределяет сомнительное управление средой. - person Max DeLiso; 24.01.2013
comment
чтобы убедиться в этом, дважды выполните следующую команду в командной строке Windows. установить FOO=BAR && echo %FOO% - person Max DeLiso; 24.01.2013