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

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

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

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

Версии исходного кода

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

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

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

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

Кодирование

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

Почему?

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

@монжардин

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

@ру

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

@джош

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

У меня есть хороший опыт разработки кода 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, а в идеале также некоторые функции рефакторинга. Меня удивляет, что сегодняшние Linux IDE даже близко не стоят с тем, чем была Visual Studio 6 более десяти лет назад. Самая большая проблема сейчас заключается в том, насколько медленным и плохо реализованным является intellisense в Netbeans. Заполнение занимает 2-3 секунды на быстрой машине с 8 ГБ ОЗУ. Intellisense Eclipse CDT зависал еще больше. Извините, но 2-секундное ожидание IntelliSense не помогает.

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

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

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

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

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

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

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

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

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

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

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

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