Использование Visual Studio для разработки на C ++ для Unix

Question

Есть ли у кого-нибудь истории о попытках использовать Visual Studio для разработки приложений для Unix? И я не говорю об использовании .NET с виртуальной платформой Mono или Wine, работающей под ней.

В нашей компании работает около 20 разработчиков, работающих под управлением Windows XP / Vista и занимающихся преимущественно разработкой для Linux и Solaris. До недавнего времени мы все заходили на основной сервер Linux и модифицировали / создавали код по-старому: Emacs, Vi, dtpad - выбирайте сами. Тогда кто-то сказал: «Эй, мы живем в темные века, мы должны использовать IDE».

Итак, мы опробовали несколько и решили, что Visual Studio была единственной, которая отвечала бы нашим требованиям к производительности (да, я уверен, что IDE X - очень хорошая IDE, но мы выбрали VS).

Проблема в том, как настроить вашу среду так, чтобы файлы были доступны локально для VS, но также были доступны для сервера сборки? Мы остановились на написании плагина Visual Studio - он записывает наши файлы локально и на сервер сборки всякий раз, когда мы нажимаем «Сохранить», и у нас есть немного толстая кнопка «синхронизация», которую мы можем нажать, когда наши файлы изменяются на стороне сервера (например, когда мы обновляем до последних файлов с нашего сервера контроля версий).

Плагин также использует функцию внешней системы сборки Visual Studio, которая в конечном итоге просто устанавливает ssh на сервер сборки и вызывает нашу локальную утилиту "make" (которая является Boost Build v2) с большой проверкой зависимостей, но на самом деле действительно медленный запуск в результате, т.е. 30-60 секунд до начала). Результаты передаются обратно в Visual Studio, поэтому разработчик может щелкнуть по ошибке и перейти к соответствующей строке кода (на самом деле, довольно изящно). Сервер сборки использует GCC и выполняет кросс-компиляцию всех наших сборок Solaris.

Но даже после того, как мы все это сделали, я не могу не вздыхать, когда начинаю писать код в Visual Studio. Я щелкаю по файлу, начинаю печатать, и VS chugs, чтобы догнать меня.

Есть ли что-нибудь более раздражающее, чем необходимость останавливаться и ждать ваших инструментов? Выгоды ли стоят разочарования?

Мысли, рассказы, помощь?

Answer 1

Я делаю то же самое на работе. Я использую установку VS для разработки Windows, с виртуальной машиной Linux, работающей под VirtualBox для локальной проверки сборки / выполнения. В VirtualBox есть средство, позволяющее сделать папку на хост-ОС (в моем случае, Windows 7) доступной в качестве монтируемой файловой системы в гостевой системе (в моем случае, Ubuntu LTS 12.04). Таким образом, после того, как я запустил сборку VS и сохранил файлы, я могу немедленно запустить make под Linux, чтобы убедиться, что он там собирается и работает нормально.

Мы используем SVN для управления исходным кодом, конечной целью является машина Linux (это игровой сервер), поэтому используется тот же make-файл, что и в моей локальной сборке Linux. Таким образом, если я добавляю файл в проект / изменяю опцию компилятора, обычно добавляя / меняя -D, я делаю изменения первоначально под VS, а затем немедленно изменяю make-файл Linus, чтобы отразить те же самые изменения. Затем, когда я фиксирую, система сборки (Bamboo) получает изменения и выполняет собственную проверку сборки.

Трудно заработанный опыт говорит, что это на порядок проще, если вы строите так с первого дня.

Первый проект, над которым я работал, начинался только под Windows, меня наняли для его переноса на Linux, поскольку они хотели переключиться на однородную серверную среду, а все остальное - Linux. Переоборудование проекта Windows в подобную установку было довольно серьезным расходом усилий.

Проект номер два был сделан "сборкой двух систем" с самого первого дня. Мы хотели сохранить возможность использовать VS для разработки / отладки, поскольку это очень отлаженная среда IDE, но у нас также было требование для окончательного развертывания на серверах Linux. Как я упоминал выше, когда проект создавался с учетом этого с самого начала, он был совершенно безболезненным. Худшей частью был один файл: system_os.cpp, который содержал специфичные для ОС подпрограммы, такие как «получить текущее время с начала эпохи Linux в миллисекундах» и т. Д. И т. Д. И т. Д.

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

Answer 2

Проверьте "Final Builder" (http://www.finalbuilder.com/). Выберите систему управления версиями (например, cvs или svn, если честно, cvs лучше подойдет для этого конкретного случая использования по звукам), а затем настройте сборку запускается в FinalBuilder, так что проверки вызывают компиляцию и отправляют результаты обратно вам.

Вы можете настроить наборы правил в FinalBuilder, которые запрещают вам регистрировать / сливать неработающий код в базовую линию или определенные папки веток, но разрешают это другим (мы не разрешаем нарушать фиксацию в / baseline или / branch / *, но мы иметь папку / wip / branching для разработчиков, которым необходимо поделиться потенциально испорченным кодом или просто захотеть сделать коммит в конце дня).

Вы можете распределить FB по нескольким «серверам сборки», чтобы у вас не было 20 человек, пытающихся собрать на одном блоке или ожидающих, пока один блок обработает все маленькие битовые коммиты.

В нашем проекте есть сервер на базе Linux с клиентами Mac и Win, которые имеют общую кодовую базу. Эта установка работает смехотворно хорошо для нас.

Answer 3

Мы используем решение, аналогичное описанному вами.

Наш код хранится на стороне Windows, и UNIX (точнее, QNX 4.25) имеет доступ через монтирование NFS (благодаря сервисам UNIX для Windows). У нас есть ssh в UNIX для запуска make и канал для вывода в VS. Доступ к коду быстрый, сборка идет немного медленнее, чем раньше, но наша самая длинная компиляция в настоящее время занимает не более двух минут, не так уж и много.

Использование VS для разработки под UNIX стоило усилий для его настройки, потому что теперь у нас есть IntelliSense. Меньше печатать = счастливый разработчик.