Использование 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

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

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

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

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

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

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

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

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

Кодирование

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

Почему?

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

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

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

Удачи!

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

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

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

Спасибо

Christophe

Answer 7

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

Answer 8

@ monjardin

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

@ РОО

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

@ Josh

Хлоп! Это звучит как отличный способ внести ошибки! : -)

Answer 9

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

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

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

Answer 10

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

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