Что такое хороший способ создать множество небольших инструментов в Visual Studio?

Question

Предположим, у вас есть некоторый исходный код из мира Unix. Этот источник состоит из нескольких файлов, которые создадут библиотеку, и множества небольших файлов .c (скажем, 20 или около того), которые скомпилированы в инструменты командной строки, каждый со своей собственной функцией main(), которая будет использовать библиотеку.

В unixy системах вы можете легко использовать make-файл, но наиболее наивное преобразование в мир Windows / Visual Studio заключается в создании отдельного проекта для каждого инструмента, который, хотя и работает, требует большой работы по настройке и синхронизировать и сложнее ориентироваться как на файловой системе, так и на уровне проекта / решения. Я думал об использовании разных конфигураций, когда все, кроме одного .c файла исключаются из сборки, но это сделало бы невозможным создание всех инструментов сразу.

Есть ли хороший способ собрать все инструменты из одной "вещи" (проекта, файла msbuild и т. Д.)?

Меня не интересует использование gcc / mingw или NAnt в Cygwin. Я бы хотел как можно больше придерживаться стандартного набора инструментов Windows.

Answer 1

Так что я уже давно занимаюсь этим, и все решения оставляют желать лучшего.

Вы можете ...

• Создание множества небольших проектов вручную.

• Используйте MSBuild и разберитесь с его крутой кривой обучения.

• Используйте инструмент сборки, который плохо интегрируется с Visual Studio, как GNU make.

Вы даже не можете создать шаблон проекта, как в проектах .NET! Ну, вы можете создать волшебника, если хотите просмотреть документы, как я полагаю. Лично я решил пойти с решением "много маленьких проектов" и просто иметь дело с ним. Оказывается, это может быть менее ужасно, чем я думал, хотя это все еще отстой. Вот что я сделал в Visual Studio 2008:

1. Создайте свой первый проект инструмента командной строки Win32, отключите все настройки для всех платформ и убедитесь, что он работает при любых обстоятельствах. Это будет ваш «шаблон», поэтому вы не хотите редактировать его после того, как сделали 20 копий.

2. (необязательно) Я установил свои пути в файлах проекта Visual Studio так, чтобы все было встроено в каталог проекта, а затем у меня есть пошаговое копирование только тех файлов dll / exe / pdb, которые мне нужны $ (SolutionDir) $ (OutDir). Таким образом, вы можете перейти в один каталог, чтобы проверить все ваши инструменты и / или обернуть их для двоичного распределения. VS2008 кажется безумным и повсюду сбрасывает выходные папки, причем расположение по умолчанию для Win32 и x64 отличается. Потратив несколько минут, чтобы убедиться, что все платформы совместимы, окупится позже.

3. Очистите свой шаблон. Избавьтесь от любых пользовательских файлов настроек и вывода компилятора.

4. Скопируйте и вставьте ваш проект столько раз, сколько вам нужно. Один проект на инструмент.

5. Переименуйте каждую скопированную папку проекта и файл проекта в новое имя инструмента. Откройте файл проекта в текстовом редакторе, таком как Notepad ++. Если у вас простой однофайловый проект, вам нужно изменить имя проекта в двух местах в начале файла и имена файлов исходного кода в конце файла. Вам не нужно прикасаться к элементам конфигурации посередине.

6. Вам также необходимо изменить GUID для проекта. Откройте файл guidgen.exe (в каталоге bin SDK) и используйте последнюю настройку переключателя. Скопируйте и вставьте новый GUID в каждый файл проекта в верхней части. Если у вас есть зависимости, в нижней части файла рядом с исходным кодом будет один или несколько идентификаторов GUID. НЕ меняйте их, так как они являются GUID из зависимостей и должны совпадать!

7. Зайдите в Visual Studio, откройте главное решение и добавьте свои проекты инструментов.

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

Это не красиво, но работает и стоит времени на настройку, чтобы иметь возможность контролировать свои сборки из GUI. Надеюсь, VS2010 будет лучше об этом, но я не слишком надеюсь. Похоже, что в наши дни MS больше любит сообщество .NET, чем сообщество C / C ++.

Answer 2

Вы не ИМЕЕТ использовать Visual Studio для компиляции кода. Вы можете создать свой собственный пакетный файл или скрипт Powershell, который просто вызывает компилятор в вашем источнике, как make-файл.

Answer 3

Если у вас есть make-файл, вы можете использовать проект 'makefile' в Visual Studio (который в неправильном названии - он просто позволяет указывать пользовательские команды сборки / отладки) и использовать его для вызова GNU make.

Вам нужно будет изменить make-файл, чтобы использовать инструменты командной строки VC ++ вместо cc или gcc или чего-либо еще, но он часто указывается макросами в верхней части make-файла.

Если make-файл использует другие специфичные для Unix команды (например, rm), вам может потребоваться внести изменения или создать файлы bath для сопоставления команд с эквивалентами Windows. Другой вариант - установить все необходимые инструменты из GNUWin32 , чтобы он работал.

Если сборка очень сложная или включает сценарии настройки, тогда у вас более сложная задача. Вы можете сгенерировать make-файл из скрипта configure, используя MSYS / MinGW, а затем изменить его, как указано выше, чтобы он работал с VC ++.

Проекты Makefile, однако, не будут так тесно интегрированы в Visual Studio. Все управление сборкой зависит от вас и от make-файла.

Answer 4

Если вы действительно используете Visual Studio, я бы предложил создать проект для каждого инструмента и добавить эти проекты в одно решение. В Visual Studio легко создать полное решение за один раз, и MSBuild также знает, как создавать файлы .sln.

msbuild myslnfile.sln

или даже:

msbuild

... создаст ваше решение.