LINUX.ORG.RU

Ядро Linux в Eclipse CDT

 , ,


2

2

Решил открыть в последнем (4.14) Eclipse CDT проект на C, использующий Makefile в свободной форме.

Что ж, проиндексировалось и открылось всё весьма быстро и, как видно, сам Eclipse в памяти занимает меньше 1 ГБ. И да, я могу вручную (ни о каком автоопределении целей, как это умеет remake, речи не даже идёт) добавить произвольные цели make (make targets) и собрать их (см. окно «Build Targets» справа).

Но на этом плюсы заканчиваются.

Eclipse не обрабатывает Makefile’ы и не строит базу данных компиляции в процессе создания проекта и потому индексирует тупо всё, что попадётся под руку. Это значит, что список включённых в проект файлов (часть модулей же обычно исключена из .config), равно как и #define’ы, ему априори неизвестны, и ни о каком точном рефакторинге говорить нельзя.

Более того, часть (включённого) кода в редакторе «сияет красным», и мне сообщают об ошибках, которых нет. Так, на снимке на 324-й строке fs/btrfs/async-thread.c Eclipse не может определить тип переменной work, хотя и ежу понятно, что это тип struct btrfs_work *, и этот тип определён в лежащем рядышком хедере. При попытке навигации к объявлению переменной work (хотя это локальная переменная в btrfs_work_helper()) мне предлагается 100500 кандидатов, разбросанных по всему проекту (диалог Open Declaration).

Вердикт – текстовый редактор, не более. Я, как давний пользователь и поклонник Eclipse, реально разочарован.

Несколько обязательных комментариев:

  • WM – WindowMaker
  • Тема оформления GTK3 – Greybird. К сожалению, только в «штатных» темах Adwaita, Greybird и Numix Eclipse выглядит удовлетворительно (в силу того, что разработчики SWT сделали ряд «хаков» для поддержки этих конкретных тем оформления), хотя, напр., поля ввода по-прежнему выглядят гигантскими. Сами разработчики рекомендуют попробовать отключить вышеупомянутые «хаки» (-Dorg.eclipse.swt.internal.gtk.noThemingFixes, см. bug 527729) и включить Clearlooks-Phénix, но, на мой взгляд, там работы ещё непочатый край: кнопки панели инструментов становятся раза в полтора больше и «уезжают» вправо.
  • Да, ШГ. Да, «кровь из глаз». Да, я всё это уже не раз слышал.

>>> Просмотр (1920x1200, 146 Kb)

★★★★

Проверено: cetjs2 ()

ШГ. «кровь из глаз». Настрой Eclipse, раз давний поклонник. Идея натравить на ядро IDE поражает самим фактом своего возникновения.

t184256 ★★★★★ ()

Сделай генератор clangdb для ядра, думаю, eclipse его умеет. Как вариант - можно сделать враппер для gcc который будет записывать выполненные команды и собрать начисто, хотя лучше конечно создать цель если это возможно в текущей структуре ядра. Мейкфайл ядра сложный и надеяться что он автоматически обработается бессмысленно

mittorn ★★★★★ ()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от mittorn

Я для себя давно сделал clangdb для ядра и редактирую в кутикрейторе. Подсветка есть, автодополнение работает. Ну ты и сам знаешь как clangdb работает в QtC.

a1batross ★★★★★ ()

Eclipse не обрабатывает Makefile’ы и не строит базу данных компиляции в процессе создания проекта и потому индексирует тупо всё, что попадётся под руку. Это значит, что список включённых в проект файлов (часть модулей же обычно исключена из .config), равно как и #define’ы, ему априори неизвестны, и ни о каком точном рефакторинге говорить нельзя.

А кто так вообще умеет?

Дайте две.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

Мне понравилось оформление, надо будет себе что-то подобное сделать.

https://code.visualstudio.com/download

Памяти ест не намного больше чем эклипс, а работает значительно лучше, особенно если для разработки используются виртуалки, нормальные тёмные темы. Надо поставить расширение для С/С++, мейкфайлы не парсит, любой более-менее сложный проект надо будет поднастроить руками. Работает не идеально, но точно лучше чем эклипс, особенно в плане UX/UI.

Увидел его здесь в галерее, кто-то на фортране что-то в нём делал, про эклипс и все ИДЕ на джаве с тех пор забыл.

aleksey_tulinov ()
Ответ на: комментарий от intelfx

Шо и цлион не справляется? )

А кто так вообще умеет?

Через compilation database умеют CLion и Sourcetrail. Но создание/обновление compile_commands.json – это дополнительные приседания.

Собственными средствами (анализ вывода make, переопределение fopen() и execve() через LD_PRELOAD, а также подмена $(MAKE), $(SHELL) и $(CC)) уже много лет умеют NetBeans и Sun Studio, хотя они уже 4 года не обновлялись.

Я всё жду, когда Oracle, наконец, созреет и передаст код модуля CND в Apache Foundation. Вот что пишут в Release Notes:

The donation of the NetBeans C and C++ features from Oracle to Apache was not complete at the time of the 11.2 release, though it is not far off, and the 11.3 release (January 2020) is scheduled to focus primarily on the integration of the C and C++ features, once they land in the Apache NetBeans GitHub. Until then, go to the Plugin Manager, enable the NetBeans IDE 8.2 Update Center, which lets you install the NetBeans IDE 8.2 modules providing C and C++ features.

P. S. Sourcetrail, кстати, – охренительная штука, рекомендую.

Bass ★★★★ ()
Ответ на: комментарий от aleksey_tulinov

VSCode всем хорош, только он превращается в тыкву^W обычный редактор, как только на более-менее сложных проектах (то же ядро Linux) его эвристики перестают работать.

Как только попытка создать проектную модель терпит фиаско, VSCode мудро отключает все инспекции, т. е. «красный» код немедленно становится «идеальным кодом».

В этом смысле Eclipse хотя бы ведёт себя честнее.

Но оба инструмента смотрятся бледно на фоне альтернатив.

Bass ★★★★ ()
Ответ на: комментарий от Bass

Неплохой визуализатор дерева исходного текста со связями, жаль что это не часть иде. Ну и с другой стороны как-то так же код можно изучать через ctrl прыгая по файлам или примитивно через find и grep правда не так удобно наверное будет )

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

abcq ()
Ответ на: комментарий от t184256

Идея натравить на ядро IDE поражает самим фактом своего возникновения.

Почему? А где же ещё должна создаваться система, как не в IDE? Неужели в текстовом редакторе без автодополнения (разработчик автодополнения должен держать у себя в голове)?

В своё время TurboPascal и Delphi писались в самих себя и пересобирались.

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 1)
Ответ на: комментарий от Bass

А можно поподробнее про «эвристики»? У меня он либо работает при наличиии информации о параметрах компиляции для текущего файла, либо «становится блокнотом». Юзаю на проектах с большой кодовой базой, (C++ + CMake). Никаких эвристик не замечал никогда. А вот тот же QtCreator меня в свое время изврядно доставал, путаясь в инклюдах и подсовывая системные инклюды вместо тех, что реально использовались при сборке.

roof ★★ ()

Экслипс сейчас вообще развивается? Я думал он уже на пару с нетбинсом отправился к апачам.

Im_not_a_robot ★★★★★ ()

Для получения compiler database, есть такая прекрасная утилита, как bear.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Для получения compiler database, есть такая прекрасная утилита, как bear.

Да, она по ссылкам в исходном тексте присутствует. Наряду с compiledb.

Только работают они по-разному. bear, насколько я понимаю, делает упор на LD_PRELOAD. Он быстрее, но совершенно бесполезен на оффтопике и, с некоторых пор, на Mac OS X 10.11+ заводится не сразу.

compiledb же подменяет $(MAKE).

Bass ★★★★ ()
Ответ на: комментарий от Bass

А, прикольно, не знал. Ну у меня с выхлопом конкретно bear не припомню когда были проблемы. Единственное неудобство, что перед началом работы над большим проектом его приходится собрать.

pon4ik ★★★★★ ()
Ответ на: комментарий от Bass

Из моего опыта, на достаточно сложных проектах ломаются все без исключения IDE, особенно если это C++, нет такого IDE которое бы где-то не ломалось. Не важно что это, Eclipse, vscode или что-то ещё, они все находят место где сломаться и там ломаются. vscode в этом случае откатывается на теги и становится чем-то типа vim + ctags + omni completion, что не плохо, потому что IntelliSense всё равно где-нибудь сломается, а теги работают всегда. Но это кому что нравится.

При попытке навигации к объявлению переменной work (хотя это локальная переменная в btrfs_work_helper()) мне предлагается 100500 кандидатов, разбросанных по всему проекту

Это очень знакомо, хотя я уже успел забыть, но сразу вспомнил. Это классика эклипса, его надо настраивать под каждый проект долго и упорно, и нет гарантии, что он в итоге заработает как хочется. Это не особенность конкретно эклипса, просто на С и С++ разные IDE обламываются в разных местах, кто-то попарсил мейкфайл и обломался чуть позже, кто-то не попарсил и обломался раньше, или наоборот, а где-то и мейкфала-то нет, его ещё надо сгенерировать из симейк-скриптов, и не факт, что в результате генерации получится мейкфайл. Такое.

aleksey_tulinov ()
Ответ на: комментарий от iZEN

А где же ещё должна создаваться система, как не в IDE?

Если система = 100500 мильенов низкоуровневой сятины, то

в текстовом редакторе

без автодополнения (разработчик автодополнения должен держать у себя в голове)?

Как настроишь. Вообще удачи, ядро большое, пространств имён в C не особо завезли.

t184256 ★★★★★ ()
Ответ на: комментарий от roof

А можно поподробнее про «эвристики»?

Не могу апеллировать к коду (я его не смотрел), но, по ощущениям, find references и goto symbol ведут себя недетерминированно. Ну, т. е., всяко лучше, чем в Eclipse, но хуже, чем в инструментах, умеющих честно строить проектную модель (NetBeans) или поддерживающих clangdb (CLion).

Это первое, что бросается в глаза при открытии того же ядра в VSCode.

P. S. Думаю, что в случае проектов на CMake всё гораздо проще и предсказуемее.

Bass ★★★★ ()
Последнее исправление: Bass (всего исправлений: 4)
Ответ на: комментарий от sanaris

Это был бутстрап для среды на Object Pascal. Потом написаи на Паскале и откомпилировали - получилось быстрее и надёжнее. Встроенный дебаггер помогал видеть текущее состояние переменных во время пошаговой отладки.

iZEN ★★★★★ ()

Пользуясь случаем. А сколько сейчас строк кода в нынешнем ядре?

gnu_linux ()
Ответ на: комментарий от Im_not_a_robot

1с-ники зачемто пилят на его основе свой конфигуратор.

PlaQ ()

Да, ШГ. Да, «кровь из глаз».

Но у тебя на скрине как раз нет ШГ.

LamerOk ★★★★★ ()
Ответ на: комментарий от Bass

P. S. Sourcetrail, кстати, – охренительная штука, рекомендую.

@metaprog, смотри, квадратики со стрелочками! Фас!

DELIRIUM ★★☆☆☆ ()

Шёл 21 век. Люди открывали С/С++ проекты и плакали... :)

Ребят, а чего, вам совсем не хочется подняться на уровень выше? Люди «Ди» пилят, библиотечки всякие, врапперы... неужели для ваших поделий недостаточно? Сам язык - прекрасная «работа над ошибками С++», не даром называется D. Перспективный язык, особенно если ПОКА ЧТО не особо нужен ГУЙ.

matumba ★★★★★ ()

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

Все остальное можно рассматривать как большую библиотеку и изучать в каком нибудь браузере ядра, в т.ч. онлайн.

zudwa ()

Прочёл Лinux, а оказалось это /linux. Вот это я понимаю ШГ!

RazrFalcon ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)