Использование 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), имеет отличную проверку зависимостей, но в действительности запускается очень медленно, т.е. 60 секунд до начала). Результаты передаются обратно в Visual Studio, чтобы разработчик мог щелкнуть по ошибке и перейти к соответствующей строке кода (на самом деле довольно изящно). Сервер сборки использует GCC и выполняет кросс-компиляцию всех наших сборок Solaris.

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

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

Мысли, истории, помощь?

19.08.2008 03:16:05
Не использование IDE не темные века.
alternative 7.09.2010 22:32:30
13 ОТВЕТОВ

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

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

1
19.08.2008 03:24:23

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

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

3
19.08.2008 03:58:22

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

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

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

0
19.08.2008 04:08:02

Сетевые акции.

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

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

1
19.08.2008 04:20:08

@monjardin

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

@roo

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

@josh

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

1
19.08.2008 14:10:22

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

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

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

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

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

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

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

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

кодирование

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

Почему?

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

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

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

Удачи!

7
17.10.2008 06:57:01

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

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

2
17.10.2008 07:57:46

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

2
10.11.2008 19:51:38

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

1
10.11.2008 20:02:04

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

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

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

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

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

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

Спасибо,

Christophe

1
1.04.2009 18:03:34

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

1
31.08.2009 21:44:39

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

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

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

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

0
24.01.2010 01:43:45

Я делаю то же самое на работе. Я использую установку 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 в миллисекундах» и т. Д. И т. Д. И т. Д.

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

0
14.09.2014 04:29:36