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

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

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

Мысли, рассказы, помощь?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

@monjardin

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

@roo

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

@josh

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

Answer 6

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

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

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

Исходный код Versioning

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

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

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

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

Кодирование

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

Почему?

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

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

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

Удачи вам!

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

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

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

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

Спасибо,

Christophe

Answer 11

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

Answer 12

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

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

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

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

Answer 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 в такой конфигурации было довольно значительной затратой усилий.

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

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