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

Есть ли у кого-нибудь боевые истории, которыми можно поделиться, пытаясь использовать 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 пыхтит, чтобы меня догнать.

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

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

Ответов (13)

Вау, это звучит очень странно для использования Visual Studio. Я очень рада, что продолжаю пыхтеть в vim. Однако единственное, что мне нравится в Visual Studio, - это отладчик. Похоже, вы его даже не используете.

Когда я открыл вопрос, я подумал, что вы, должно быть, имеете в виду разработку переносимых приложений в Visual Studio, а затем их перенос на Solaris. Я сделал это и получил приятный опыт.

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

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

Прежде чем продолжить, я должен признаться, что все это было сделано в VS6 + CVS, а в последнее время и в SVN.

Управление версиями исходного кода

У разработчиков есть отдельные репозитории с безопасным исходным кодом, чтобы они могли хранить свою работу и проверять ее пакеты работ на логических этапах. Когда они чувствуют, что хотят провести интеграционный тест, мы запускаем скрипт, который проверяет его в SVN.

После регистрации в SVN у нас запускается процесс, который автоматически генерирует соответствующие make-файлы для их компиляции на целевых машинах для непрерывной интеграции.

У нас есть еще один набор скриптов, который синхронизирует новый материал из SVN с папками, за которыми работает VS. Есть небольшой пробел, потому что VS не может автоматически подбирать новые файлы; мы обычно делаем это вручную. Это происходит регулярно только в первые несколько дней проекта.

Это обзор того, как мы поддерживаем коды. Должен сказать, что я, вероятно, замалчил некоторые детали (дайте мне знать, если вам интересно).

Кодирование

С точки зрения кодирования мы в значительной степени полагаемся на препроцессоры (например, #define и т. Д.) И флаги в make-файле для формирования процесса компиляции. Для кроссплатформенной переносимости мы используем GCC. Несколько раз нас заставляли использовать aCC в HP-UX и некоторых других компиляторах, но особого горя у нас не было. Единственное, что вызывает постоянную боль, - это то, что нам приходилось следить за пространством кучи потоков на разных платформах. Компилятор от этого не избавляет.

Почему?

Обычно возникает вопрос: «Зачем вам вообще, что иметь такой сложный путь развития?». Нашим ответом обычно является другой вопрос: «Вы хоть представляете, насколько безумно отлаживать многопоточное приложение, исследуя дамп ядра или используя gdb?». По сути, тот факт, что мы можем отслеживать / проходить по каждой строке кода при отладке неясной ошибки, делает все это стоящим усилий!

Плюс! ... Функция intellisense в VS позволяет легко находить метод / атрибут, принадлежащий классам. Я также слышал, что VS2008 имеет возможности рефакторинга. Я переключил свое внимание на Java на Eclipse, в котором есть обе функции. Вы будете более продуктивны, сосредоточившись на написании бизнес-логики, чем тратите энергию на то, чтобы заставлять свой ум делать такие вещи, как запоминание !

Также! ... В итоге мы получили бы продукт, который может работать как в Windows, так и в Linux!

Удачи!

Вы можете поручить разработчикам работать в частных филиалах (проще, если вы используете DVCS). Затем, когда вы хотите проверить какой-то код, вы регистрируете его в своей частной ветке в [windows | unix], обновляете свою песочницу в [unix | windows] и строите / тестируете, прежде чем возвращаться в основную ветку.

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

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

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

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

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

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

Я чувствую твою боль. У нас есть кроссплатформенное приложение. Типичное клиент-серверное приложение, в котором клиент должен иметь возможность работать в Windows и Linux. Поскольку наша клиентская база в основном использует окна, мы работаем с VS2008 (отладчик значительно упрощает жизнь), однако нам по-прежнему необходимо выполнять сборки Linux.

Основная проблема заключалась в том, что мы проверяли код, который, как мы не знали, будет построен под gcc, что, скорее всего, нарушит работу CI, которую мы настроили. Итак, мы установили MingGW на все машины нашего разработчика, что позволяет нам проверить, что рабочая копия будет построена под gcc, прежде чем мы вернем ее обратно в репозиторий.

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

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

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

Сетевые ресурсы.

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

Вы не хотите слышать, что я делал, когда разрабатывал для обеих платформ. Но вы собираетесь: копировать с перетаскиванием несколько раз в день. Локальная сборка и запуск, а также периодическая проверка его в Unix, чтобы убедиться, что gcc был доволен, и что модульные тесты тоже были успешными на этой платформе. На самом деле это не совсем быстрый цикл оборачиваемости.

@monjardin

Основная причина, по которой мы его используем, - это инструменты рефакторинга / поиска, предоставляемые через Visual Assist X (от Whole Tomato). Хотя есть ряд других приятных вещей, таких как Intelli-sense. Мы также изучаем возможности интеграции с другими нашими инструментами AccuRev, Bugzilla и Totalview для завершения среды.

@roo

Использование нескольких компиляторов похоже на боль. У нас есть возможность просто использовать gcc для всех наших платформ.

@josh

Ой! Звучит как отличный способ вносить ошибки! :-)

Разрабатываем под Mac и ПК. Мы просто работаем локально в любом идеале, который предпочитаем, в основном VS, но также и xcode. Когда мы чувствуем, что наши изменения достаточно стабильны для серверов сборки, мы регистрируем их. Два сервера сборки (Mac и ПК) ищут проверки системы управления версиями, и каждый выполняет сборку. Ошибки сборки отправляются команде по электронной почте.

Редактирование файлов в реальном времени на сервере сборки кажется мне опасным. Что произойдет, если вы запросите сборку, в то время как другой разработчик внесет правки, которые не могут быть построены?

Я знаю, что это на самом деле не отвечает на ваш вопрос, но вы можете подумать о настройке удаленных сеансов X и просто запустить что-то вроде KDevelop , который, кстати, является очень хорошей IDE, или даже Eclipse , что больше мейнстрим и имеет более широкую базу разработчиков. Вероятно, вы могли бы просто использовать что-то вроде Xming в качестве X-сервера на своих машинах с Windows.

У меня был хороший опыт разработки кода Playstation2 в Visual Studio с использованием gcc в cygwin . Если у вас есть cygwin с gcc и glibc, он должен быть почти идентичен вашей целевой среде. Тот факт, что вы должны быть переносимыми между Solaris и Linux, намекает, что cygwin должен работать нормально.

Большая часть моего опыта программирования связана с Windows, и я большой поклонник Visual Studio (особенно с Resharper, если вы занимаетесь кодированием на C#). Сейчас я пишу приложение для Linux на C++. Попробовав все IDE (Netbeans, KDevelop, Eclipse CDT и т. Д.), Я обнаружил, что Netbeans наименее дрянной. Для меня абсолютные минимальные требования заключаются в том, чтобы я мог выполнять код за один шаг и иметь intellisense с, в идеале, некоторыми функциями рефакторинга. Меня удивляет, насколько сегодняшняя среда IDE для Linux даже близко не похожа на Visual Studio 6 более десяти лет назад. Самая большая проблема сейчас - это то, насколько медленно и плохо реализован intellisense в Netbeans. Для заполнения на быстрой машине с 8 ГБ ОЗУ требуется 2-3 секунды. Intellisense Eclipse CDT был еще более медленным. Мне жаль,

Итак, теперь я изучаю использование VS из Windows, хотя моя единственная цель сборки - Linux ...

Крис, вы можете посмотреть на бесплатный сервер сборки автоматизации CruiseControl, который интегрируется со всеми основными системами управления версиями (svn, tfs, sourcesafe и т. Д.). Вся его цель - реагировать на проверки в системе управления версиями. Как правило, вы настраиваете его так, чтобы каждый раз, когда кто-либо проверял код, запускалась сборка и (в идеале) запускались модульные тесты. Для некоторых языков есть отличные плагины, которые выполняют анализ кода, измеряют покрытие кода модульных тестов и т. Д. Команде отправляются уведомления об успешных / неработающих сборках. Вот сообщение, описывающее, как его можно настроить для C++: ссылка (thinkworks.org) .

Я только начинаю переходить от простой конфигурации только для Linux (Netbeans + SVN, без автоматизации сборки) к использованию Windows VS 2008 с серверной частью автоматизации сборки, которая запускает модульные тесты в дополнение к сборкам в Linux. Я вздрагиваю от того, сколько времени у меня уйдет на то, чтобы все это настроить, но, полагаю, чем раньше, тем лучше.

В моем идеальном конечном состоянии я смогу автоматически сгенерировать файл проекта Netbeans из проекта VS, чтобы, когда мне нужно что-то отладить в Linux, я мог сделать это из этой IDE. Файлы проекта VS основаны на XML, так что это не должно быть слишком сложно.

Если у кого-то есть какие-либо указатели на это, я был бы очень признателен.

Спасибо,

Кристоф

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

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

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

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