Вот в недавнее время занимался выбором удобной среды разработки для С\С++\Perl и в итоге пришёл к выводу, что удобоваримых сред разработки нету как таковых...ну, давайте по порядку.
Сначала пролистал среды разработки заточенные специально под Qt4, среди которых оказались:
Edyuk,
QDevrlop,
MonkeyStudio, все программы собирались напрямую из SVN, дабы получить наиболее полное представление о новых функция и задумках авторов (а иногда это было уже вынужденной мерой, т.к. RPM пакетов под мою 64 разрядную систему не было как таковых).
Общее впечатление от программ весьма неплохое, почти все используют (или пытаются использовать) интеграцию с QDesigner (редактор графического интерфейса для Qt), имеют меню просмотра файлов проекта, а также просмотр структуры классов, описанных в файлах проекта. Настройки редакторов кода достаточно скудны, следовательно, гибкости ожидать не стоит. Очень порадовали шаблоны Qt4 приложений основных видов (Dialog based, Application и Console Applocation) в QDevelop, опция из разряда - мелочь, а приятно).
Ну что в итоге мы имеем, более-менее функционирующие (зависания были достаточно часты, но это не недостаток программ - все же я их брал из репозиториев разработки и этого следовало ждать), со всеми джентльменскими функциями, почти во всех программах (которые внешне были достаточно сильно похожи, что заставляет задуматься об общем их прародителе) присутствовал встроенный отладчик и возможность удобной (без привлечения внешних средств) сборки Qt4 приложений. Хотелось бы ещё отметить, что сборка QDevelop осуществляется посредством универсальной системы сборки
CMAKE, что очень меня радует, т.к. я использую именно её в своих проектах, чего и вам советую.
Но все же остаётся какой-то не очень приятный осадок от этих сред разработки - вроде бы все есть, но чего-то всегда не хватает и адекватной возможности расширить функционал не предоставляется (ну, конечно, за исключением вмешательства в исходный код этих сред). Так что на данном этапе данные среды разработки я пока оставляю, хотя не исключаю вероятности вернуться к ним позже.
Пошли далее. Как бы наиболее продвинутыми (чисто субъективное мнение) по части всевозможных фич являются среды разработки на языке Java. Мы рассмотрим Netbeans и Eclipse с плагином CDT (кстати говоря, на момент написания статьи уже вышел
плагин интеграции Qt Дизайнера для Eclipse).
Начнём с
NetBeans6beta, опять же мы работаем с самой новейшей версией (стабильной версией в данный момент считается версия 5.5.1), список возможностей которой мягко сказать поражает (они в основном ориентированы на Java). Ну вот, поставив JDK6, дополнительные 512 мб оперативной памяти (когда было 512 мб памяти работать было просто невозможно, ибо нетбинс кушал почти всю оперативную память и система вела себя подобно улитке, завязшей в студень) я приступил к изучению данной среды и её возможностей по части разработки на С++.
При создании проекта нам предоставляется выбор из четырёх возможностей - Статическая библиотека, Динамическая библиотека, Консольное приложение и создание проекта из существующих файлов. Присутствует обёртка к отладчику GDB, что похвально, вроде даже есть возможность использовать встроенный профайлер и для проектов на С++. А вместе с достаточно удобным редактором и вовсе получаем чуть ли не требуемый идеал... если бы не одно "но".
Для справки работаю я на достаточно не слабом по современным меркам ноутбуке (Turion Tl52x2,1Гб DDR2) и, казалось бы, о тормозазах и лагах давно должен был забыть, оказывается нет - Джава и иже с ней Нетбинс заставили меня вспомнить о них. Вроде бы лаг не очень большой, но достаёт просто дико, т.к. проявляется почти всегда - при переходе от одного файла проекта к другому, перед сборкой, перед запуском, в итоге по чуть-чуть и набираем лаги, очень сильно действующие на нервы.
При разработке на языке Java c лагами ещё как-то можно мириться, но на С\С++ это, увы, непозволительная роскошь (вполне вероятно, что я слишком придираюсь, но после почти мгновенных сборок посредством связки cmake+Vim, торможение очень заметно).
Далее, Eclipse, на мой взгляд, замечательная среда разработки, но опять же только для Java проектов, по этой причине, все перечисленное для Нетбинса применимо и к ней, увы. В итоге уже пять забракованных сред разработки, неплохо для начала)
KDevelop, тут уже все намного лучше, быстрая, красивая, современная многофункциональная среда разработки с поддержкой многих языков программирования, со встроенным отладчиком. А также с поддержкой моего любимого CMAKE для С\С++ проектов. Казалось бы идеал и предел желаний, но интерфейс изобилует редко используемыми функциями и для некоторых проектов функционал излишен, а также почти всегда требуется заточка под себя. Но в итоге, данной среде разработке из всех вышеперечисленных, я бы дал максимальный балл )
Ну а что в итоге? Где же мой предел мечтаний в унифицированной среде разработки для С\С++ и Перл? Я же ведь так и не сказал ни разу, что какая-либо среда мне идеально подошла. А выбор я свой сделал (и вряд ли его изменю), а именно остановился я на редакторе Vim; "Да какая же это среда разработки, это же текстовый редактор !", - можете воскликнуть Вы, но спокойствие, сейчас объясню. Vim, во-первых, поддерживает подсветку синтаксиса огромного количества языков, во-вторых, имеет собственный язык написания модулей расширения, которые призваны расширить функционал редактора посредством добавления в него новых функции. Далее в Vim есть возможность вызова внешних команд и "забора" результата их исполнения (в идеале это как раз вызов cmake). Ну и ещё очень много всего вкусного, о чём мы поговорим в дальнейших публикациях.
На данный момент стоит несколько проблем, среди них: использование вкладок в Vim (как в FireFox), удобный просмотр файлов проекта, автодополнение имён методов\классов и переменных, вызов cmake, удобный переход в командный режим в случае текущей русской раскладки (лично у меня уже руки болят переключать раскладку), а также ещё некоторые менее важные функции, которые тем не менее будут описаны в далее. В итоге я отказался от полностью интегрированных решений в пользу связки из нескольких программ - Vim, QDesigner, KGDB, cmake и нескольких собственных скриптов, которые будут интегрированы c Vim. Ну вот для введения, пожалуй, достаточно.
P.S.В данной публикации высказано моё субъективное мнение, которое может не совпадать с Вашим, но тем не менее, хотелось бы оговориться, что я никоим образом не пытаюсь выставить в плохом свете указанные программы, я лишь утверждаю, что в условиях решаемой задачи они мне не подходят и ничего более. Сразу же оговорюсь по поводу пропуска в обзоре замечательного редактора Emacs, тут сказывается уже привычка, т.к. после нескольких лет работы на Vim считаю переход на Emacs сверхсложной задачей, хотя в будущем не исключаю возможности изучения и этой платформы.
