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

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

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

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

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

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

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

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

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

Кодирование

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

Почему?

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

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

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

Удачи вам!

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

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

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

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

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

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

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

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

Сетевой ресурс.

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

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

@monjardin

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

@roo

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

@josh

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

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

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

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

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

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

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

Спасибо,

Кристоф

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

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

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

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

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

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

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

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

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

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

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

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

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

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