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

Ответ 1

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

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

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

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

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

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

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

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

Кодировка

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

Почему?

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

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

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

Удачи!

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

@monjardin

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

@roo

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

@josh

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

Спасибо,

Кристоф

Ответ 10

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

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

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

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

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

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