LINUX.ORG.RU
ФорумTalks

Что произошло с kdevelop?

 , , ,


0

7

Я видел, что тут есть люди, которые либо причастны к нему, либо просто в теме. Поэтому пишу тут.

Kdevelop мой любимый редактор и не думайте, что я обсираю, либо что-то подобное. В четвёртом всё было более-мене нормально, но он не умел в си, да и с разбором сложного С++-кода у него были проблемы. Но в целом всё было очень хорошо.

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

Я вначале грешил на шланг, но позапускав компиляцию, да и clang-check( я не особо разбираюсь, но вроде это оно) я понял, что дело не в нём. Компиляция проходит за 300-500мсек, когда как разбор кода в кдевелоп происходит за секунд 5. Хотя 300-500мсек это итак неимоверно много, но всё же куда лучше чем 5секунд.

В багтрекере есть моя проблема https://bugs.kde.org/show_bug.cgi?id=371018 и там объяснена причина по которой оно работает 5секунд. Гениальное решение - ничего не скажешь. При этом там в настройках есть задержка на запуск парсера - нахрена было её хардкорить? В конечном итоге прошло уже несколько месяцев - ничего так и не поменяли.

Ну и, собственно, мои вопросы. Занимается ли кто-то этой проблемой? Занимается ли кто-то более глобальной проблемой - либшлангом? Если да, то где. Может я смогу помочь.

Перемещено tailgunner из development

У тебя какие-то проблемы с 95-ым годом. Странно, ведь ты тогда еще не родился.

buddhist ★★★★★
()

Всю портянку не читал, но с вопросами по clang тебе в cfe-dev@lists.llvm.org, если хочешь вот прям ща ответ, то в #llvm на irc.oftc.net.

Я бегло по багу пробежался, не очень понял, какие у них конкретно претензии к libclang, чёто типа они запускают какую-то свою лабуду, а пока эта херня отрабатывает, они не могут запустить анализ через libclang. В конце концов, где у них там ссылка на багрепорт на clang?

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от mtiexpert

Ну и что ты показал?

То, что ты просил. Пример использования тобой cloc ранее вкупе с типовыми искажениями слов и является ответом на твой вопрос «Что меня выдало?»

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

Это лишь подтверждает твоё раздражение. Ты почему-то нервничаешь и начинаешь коверкать слова и делать ошибки.

Во-первых это нихрена не ранние инкарнации. Во-вторых, как я и говорил - это один тред в которым я это юзал. Это было с гцц да, а не со скулайтом. Хотя может и со скулайтом было.

Давай не будет скатывать тред про обсуждение проблем Clang/KDevelop/Something else в тред обсуждения твоей персоны.

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

Кто сказал? Nokia ничего не стоило силами своих сумрачных норвегофиннов взять этот KDevelop и обеспечить в нём:

а) Кросс-платформенное формошлёпство.
b) Кросс-платформенное формошлёпство для Nokia S60.
c) Симулятор смартфона и возможность деплоя одной кнопкой приложения на телефон.

Всё это у них уже было на блюдечке. Оставалось только обеспечить поддержку других OS для того, чтобы хомячки могли кодировать прикладухи внутри своих мирков. Разве это было сложно? Нет, учитывая, что через год KDevelop уже был кросс-платформенным. Что вместо этого в Nokia начали делать? Правильно раскопали анналы и вытащили тролльтеховский Greenhouse, который тролльтех закопал сам в пользу KDevelop, кстати (в офциальных SDK под ихний Qtopia Greenphon был именно KDevelop).

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

Я бегло по багу пробежался, не очень понял, какие у них конкретно претензии к libclang

Тормаза? У всех к либшланг претензия одна - тормаза. Я не понимаю кто как и зачем её делал, но так зфейлится надо уметь.

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

чёто типа они запускают какую-то свою лабуду, а пока эта херня отрабатывает, они не могут запустить анализ через libclang. В конце концов, где у них там ссылка на багрепорт на clang?

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

mtiexpert
() автор топика
Ответ на: комментарий от EXL

Кто сказал? Nokia ничего не стоило силами своих сумрачных норвегофиннов взять этот KDevelop и обеспечить в нём:

Ещё раз. Зачем обеспечивать это в кдвелопе, если всем нужен блокнот? Т.е. все основные фичи кдевелопа нам не нужны.

А далее всё просто - хомячкам нужны две пидали. В кдевелопе слишком много лишних пидалей. Непорядок. Что делать с этим?

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

Я не считаю, что кдевелоп дал бы что-то креатору. А всегда проще сделать заново, чем переделать. Особенно учитывая то, что кдевелоп прибит к кедам, да и стабильность у него была всегда не ахти.

Да и что бы кдевелоп получил? Развитие двух педалей? А оно ему надо? Оно как было блокнотом там и осталось. И никакой шланг ему не помог и не поможет.

mtiexpert
() автор топика
Ответ на: комментарий от mtiexpert

А что ты имеешь в виду под инкрементальным апдейтом в плане компиляции крестов?

A further difference between IDEs and batch compiler is that they often impose very different requirements on the front-end: they depend on high performance in order to provide a «snappy» experience, and thus really want techniques like «incremental compilation», «fuzzy parsing», etc. Finally, IDEs often have very different requirements than code generation, often requiring information that a codegen-only frontend can throw away. Clang is specifically designed and built to capture this information.

http://clang.llvm.org/features.html

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от EXL

А чем он слит? Вы выкатили какую-то херню. Никогда в жизни я даже представить не мог, что нужен какой-то межстрочный интервал. Это проблемы не редакторов, а уже аccessibility какое-то.

Потом начал толкать про совсем смешные вещи. Мультикурсорность настолько примитивная фича, что говорить о ней просто смешно. Умеет ли кути в мультикурсорность? Опять же. И почему ты показал идею, а не свой саблайм?

Да и в целом kate - это именно текстовый редактор, а не блокнот для веб-«профессионалов». О каком убийце ты говоришь? Хомячкам нужен пиар и пистон, а лучше жабаскрипт для плагинов. Так появился саблайм и то в мире маздайки. Я уж не говорю о таких недоразумениях как атом.

Конечно, он тормазить в дерьмо, но я лучше выберу тормазное дерьмо, чем убогое шг и говногуй. Достаточно посмотреть на этот скриншот: http://wstaw.org/m/2016/07/31/Screenshot_20160731_133225.png - проблеватсья и остаться на кате.

mtiexpert
() автор топика
Ответ на: комментарий от DELIRIUM

А что ты имеешь в виду под инкрементальным апдейтом в плане компиляции крестов?

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

http://clang.llvm.org/features.html

Это ни о чём не говорит, да и я не понял что они пытаются мне этим сказать. Я не видел и не слышал о том, что-бы что-то умело, либо шланг умел, а так же об этом не знает гугл.

Воспринимать заявления в агитках серьёзно - такая себе затея.

mtiexpert
() автор топика
Ответ на: комментарий от mtiexpert

Никогда в жизни я даже представить не мог, что нужен какой-то межстрочный интервал.

Значит ты никогда не программировал текстовые редакторы.

Это проблемы не редакторов, а уже аccessibility какое-то.

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

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

Ага. Настолько смешная и примитивная фича, что она до сих пор в отдельной ветке в том же KDevelop: https://github.com/KDE/ktexteditor/tree/multicursor, так как всё не могут оттестировать до конца. Может поможешь им? Или уже выкатили для KDevelop мультикурсорность? (я не следил за этой темой)

Да и в целом kate - это именно текстовый редактор, а не блокнот для веб-«профессионалов».

Kate это Advanced Text Editor. И он таким был во времена KDE 3.5, потому что конкурентов из хомячковых редакторов у него не было. Там он и остался. А блокнот для Web-«профессионалов» на основе того же Kate (KTextEdit Part) в KDE назывался Quanta Plus и его благополучно убили.

А теперь Kate хочет подвинуть пьедестал Sublime Text и прочих, вон, даже недавно сборочки для MacOS/Windows понаделал, а KDE-шники усиленно начали плакаться в бложиках.

Впрочем, к сабжу это имеет значение только по используемому в Kate/KDevelop компоненту: ktexteditor

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

Вы точно последнюю версию QtCreator запускали? Ну вдруг. В последней, я бы сказал, всё вполне неплохо. Не хватает подсветки собственных функций и макро, того что в инклуденных модулях, правда.

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

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

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

За Kate благодарить нужно именно старых KDE'шников, тех, которые делали его для KDE 2 и KDE 3. Это их наследие. Ничего нового по сути в KDE 4 и KDE 5 добавлено в него не было. Он остался практически неизменным с того времени.

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

Повторюсь, не видел кеды младше KDE 4.4-4.5, если даже не 4.6. Кого там и где благодарить — надо копаться в истории VCS. Ну или хотя бы в копирайтах на файл.

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

Значит ты никогда не программировал текстовые редакторы.

Чё?

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

Ты уж определись с темой. Изменяемый в настройках, либо «определить». Как я уже сказал - проблемы со зрением у автора - это не проблема редактора, а адаптации для инвалидов.

Kate (а следовательно и KDevelop) рвёт отрисовку на этом выхлопе декомпилированного класса в котором закрался китайский иероглиф.

Открыл пате - спастил ироглив - ничего не рвёт. Выкатывай свою портянку - я сделаю тебе скриншот.

Ага. Настолько смешная и примитивная фича, что она до сих пор в отдельной ветке в том же KDevelop: https://github.com/KDE/ktexteditor/tree/multicursor, так как всё не могут оттестировать до конца.

Причём тут тестировать - просто всем насрать на неё и никому она не нужна, ибо не имеет юзкейсов.

Ну глянул я на твою ветку. Хелворд на 5строк. Я что-то не так сказал? Всё так. Примитивная фича. Всё остальное - это интеграция этой фичи. Но это уже не проблема фичи, а проблема архитектуры и качества кода.

Kate это Advanced Text Editor. И он таким был во времена KDE 3.5, потому что конкурентов из хомячковых редакторов у него не было. Там он и остался. А блокнот для Web-«профессионалов» на основе того же Kate (KTextEdit Part) в KDE назывался Quanta Plus и его благополучно убили.

А что ему надо было? Мне как-то насрать на хтмл-блокнот, да и всем. Зачем тащить какую-то куанту, которая никому не нужна?

Я не понимаю - чего ты хочешь. Надо было срочно выкатывать кате под маздай и запиливать туда пистон, либо ЖС? Или что?

А теперь Kate хочет подвинуть пьедестал Sublime Text и прочих, вон, даже недавно сборочки для MacOS/Windows понаделал, а KDE-шники усиленно начали плакаться в бложиках.

Мне как-то побоку. Хомячкам нужен пиар и пистон, да и время уже упущено, а так они сожрут всё что угодно.

mtiexpert
() автор топика
Ответ на: комментарий от mtiexpert

Открыл пате - спастил ироглив - ничего не рвёт. Выкатывай свою портянку - я сделаю тебе скриншот.

Да, я сейчас посмотрел, исправили недавно в сентябре прошлого года. Я сам лично пару подобных багов им засылал, некоторые закрыли с RESOLVED DUPLICATE со ссылкой на это https://bugs.kde.org/show_bug.cgi?id=335079 Два года чинили, вот такая вот активность проекта. Грустно.

Ты не в ту степь поехал, я fenris'у совсем другое пытался там объяснить. Я ему про вот этот баг с UTF-8, он мне про шрифты. Я ему про мультикурсорность, он мне про Column Editing и т. д.

Я не понимаю - чего ты хочешь

Я хочу сказать только одно: если бы команда KDE-разработчиков была порасторопнее, то там были бы инструменты и для хомячков с пистонами и джаваскриптерами, и для прикладников крестушников, и для кернел-кодеров сишников. Всем бы нашлось место. Но они занимаются совершенно другим, в KDE 4 они прикрепляли неон к окнам, в KDE 5 они писали клизмоиды на JavaScript'е и переносили весь стек на Qt5/KF5, по пути отпиливая и выкидывая то, что работало когда-то.

А в итоге, ты и остальные пользователи без маски KDE-фанатизма, создают треды, что мол за херню они всё время там делают и почему

Стало почти невозможно работать ... всё стало ещё хуже.

А один из главных разрабов KDevelop интересуется, почему, собственно никто не юзает этот самый KDevelop даже в KDE-тусовке и для кого он, мать его, вообще старается.

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

Тормаза? У всех к либшланг претензия одна - тормаза. Я не понимаю кто как и зачем её делал, но так зфейлится надо уметь.

Вот я не знаю, как там всё работает со шлангом в QtC, но сейчас открыл какую-то большую современную крестолапшу на их новом clang-овском парсере:

http://esxi.z-lab.me:666/~exl_lab/movies/qtc_clang_speed.webm

Не чувствую я особой разницы между стоковым парсером и сегодняшним libclang. Да и задержка эта не напрягает. Пока переводишь взгляд с курсора на линейку с предупреждениями, они уже появляются. А недавно, помню, тормозил он сильно тормозил и тупил. Может потому они и не включают пока его основным.

Я до сих пор стоковый парсинг юзаю, так как у меня по работе одно легаси идёт.

Может действительно с задержками они что-то там в KDevelop сильно намудрили? Ты напиши этому Funk'у в комментсы, мол так и так, что тут за чертовщина.

Отпишись только потом к чему придёшь в конце концов, самому интересно стало. Пусть хотя бы уменьшат эти свои 5 сек до 1-2. А то планирую новый KDevelop пощупать и на деле опробовать, да руки не доходят.

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

Прикольно, работает :)

Правда, иногда при построении проекта валится на:

SOFT ASSERT: "!m_cmakeProcess" in file /work/build/qt-creator/src/plugins/cmakeprojectmanager/builddirmanager.cpp, line 392

Program received signal SIGSEGV, Segmentation fault.
0x00007fffe3c5c972 in ?? () from /opt/toolkits/QtSDK/Qt5.7.0/Tools/QtCreator/lib/qtcreator/plugins/libProjectExplorer.so
(gdb) bt
#0  0x00007fffe3c5c972 in ?? () from /opt/toolkits/QtSDK/Qt5.7.0/Tools/QtCreator/lib/qtcreator/plugins/libProjectExplorer.so
#1  0x00007fffe3c5eee5 in ?? () from /opt/toolkits/QtSDK/Qt5.7.0/Tools/QtCreator/lib/qtcreator/plugins/libProjectExplorer.so
#2  0x00007fffe3c5f26d in ?? () from /opt/toolkits/QtSDK/Qt5.7.0/Tools/QtCreator/lib/qtcreator/plugins/libProjectExplorer.so
#3  0x00007fffe3c63b0e in ?? () from /opt/toolkits/QtSDK/Qt5.7.0/Tools/QtCreator/lib/qtcreator/plugins/libProjectExplorer.so

Но это, возможно, из-за относительно старой версии Qt Creator (4.0.2).

Ты падений не наблюдаешь? Steps to reproduce у меня такие:

1. Загружаем проект твоим способом.
2. Меняем в qt-scan-all.cmake паттерн в SCAN_GLOB_EXPR.
3. Clear CMake Configuration.
4. Меняем паттерн обратно на *
5. Clear CMake Configuration.
6. Сегфолт.

Тестил на AvCpp и на искоробочном CMake.

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

Насрать на этих хомячков.

Я хочу сказать только одно: если бы команда KDE-разработчиков была порасторопнее, то там были бы инструменты и для хомячков с пистонами и джаваскриптерами, и для прикладников крестушников, и для кернел-кодеров сишников. Всем бы нашлось место. Но они занимаются совершенно другим, в KDE 4 они прикрепляли неон к окнам, в KDE 5 они писали клизмоиды на JavaScript'е и переносили весь стек на Qt5/KF5, по пути отпиливая и выкидывая то, что работало когда-то.

Ну на самом деле пятые кеды стали работать и выглядеть куда лучше четвёртых. Хотя такое себе лучше, но всё же.

Я не понимаю - кто всё это должен пилить? Полтора человека в кдевелопе, которые не могут заставить его работать? Конечно, они молодцы и я им благодарен за кдевелоп, но всё же.

Я обновился и вижу, что наконец-то маны починили, которые в пятом сломали. Конечно, конструкторы так и не завезли, да и ещё кучу фичей из четвёртого. Там всё было лучше. Я уже и не помню что там вообще было. Контекстное автодополнение вообще на днище.

И всё же - кто бы всё это пилил? Непонятно.

А один из главных разрабов KDevelop интересуется, почему, собственно никто не юзает этот самый KDevelop даже в KDE-тусовке и для кого он, мать его, вообще старается.

Я не знаю какие приоритеты у кого.

Что есть основная часть иде? Редактор? Интеграция для маздайского синдрома? Всякие убогие вау-фишечки для хомячков, типа как в идеи, либо как в саблейме?

Для меня - это редактор и на всё остальное мне плевать. Для большинства это не так. В какую сторону развиваться кдевелопу и почему ты решил, что ушли/ не прешли с/к нему не из-за этого? В креаторе интегрированы педали(особенно во всяких бубунтах/маздайках это важно), дизайнеры, доки, всякие остальные вещи из стека кути. Может там какие-то средства для говнокопания лучше?

mtiexpert
() автор топика
Ответ на: комментарий от mtiexpert

Я вот наткнулся на обсуждение clang'а (от 2010го года): http://clang-developers.42468.n3.nabble.com/How-can-I-use-incremental-compile...

- First, start with precompiled headers. You can build a precompiled header for the file you're code-completing in (which consists of, say, all of the #includes at the top). Then, Clang doesn't have to parse that code each time you run code-completion. Precompiled headers aren't yet implemented for C++, so that would be the right place to start.

- Second, teach Clang how to skip parsing function bodies when performing code completion, caching or throwing away the tokens if the code-completion token isn't within that function definition. Here, you'd hook into Clang's Parse module where it parses a function definition. That should eliminate a lot of work that won't affect how code-completion behaves.

- Finally, consider real incremental parsing. It's going to be tricky, because you would need to teach both Parse and Sema how to pretend that they're in a particular compilation context to re-parse the code you're in (e.g., if you're inside a function definition). I recommend trying this only if the other two, combined, don't make code-completion fast enough for you.

Я в этом не особо секу, я Parse и Sema не занимаюсь и ваще их ни разу не трогал. У меня абсолютно перпендикулярные этому задачи.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от EXL

Не чувствую я особой разницы между стоковым парсером и сегодняшним libclang. Да и задержка эта не напрягает. Пока переводишь взгляд с курсора на линейку с предупреждениями, они уже появляются. А недавно, помню, тормозил он сильно тормозил и тупил. Может потому они и не включают пока его основным.

Да, потому. Разница есть и она колоссальна.

По поводу твоей лапши. Современная она по меркам 95-го года. Ах да, я тебя не обижаю. А то вдруг обидишься.

Может действительно с задержками они что-то там в KDevelop сильно намудрили?

Ну так и есть. Я писал про время анализа шлангом кода. Это 300мс на хелворд. Ты получил примерно это время.

Ты напиши этому Funk'у в комментсы, мол так и так, что тут за чертовщина.

Ну постараюсь когда время будет.

Отпишись только потом к чему придёшь в конце концов, самому интересно стало. Пусть хотя бы уменьшат эти свои 5 сек до 1-2. А то планирую новый KDevelop пощупать и на деле опробовать, да руки не доходят.

Хорошо. У меня не особо есть мотивация помогать кдевелопу. Даже если уменьшить время до времени шланга, то это всё равно слишком много. Я не могу так работать.

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

И я сомневаюсь, что я что-то там могу сделать, либо кто-либо ещё. Скорее всего там проблемы вообще нерешаемые. Хотя вроде они модули пилят и возможно ими пытаются решить проблему, вернее поставить подпорку.

mtiexpert
() автор топика
Ответ на: комментарий от mtiexpert

вроде они модули пилят

Насколько я знаю, нет. Забросили, как только стало известно, что в стандарт не войдёт.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от EXL

Ну я данное решение больше как PoC сделал и сильно не напрягал тестированием :) Я свой поправленный плагин использую.

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

Ну и с деревом были проблемы. В том числе с двойным освобождением памяти. Особенно если идентичные айтемы появляются. Плюс были гонки. А если валится в ProjectExplorer, сто пудов двойное освобождение.

Кстати, залил на Gist: https://gist.github.com/h4tr3d/0b610a507ed42faeb3c32e2700fabb13 так что можно форкать и править.

Тестил на AvCpp

а ты его для каких-то реальных задач используешь? А то мне до него сейчас недосуг и, в основном, только для прототипов :)

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

Я не понимаю - кто всё это должен пилить? Полтора человека в кдевелопе, которые не могут заставить его работать? Конечно, они молодцы и я им благодарен за кдевелоп, но всё же.

В идеале, было бы неплохо, если бы KDevelop какая-нибудь компания взяла под крыло. Чтобы тот же Kevin Funk работал не на чистом энтузиазме, а получал зарплатку.

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

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

Да, нужно будет обновиться. Я не слишком часто это делаю. Последний раз вот в октябре прошлого года.

а ты его для каких-то реальных задач используешь? А то мне до него сейчас недосуг и, в основном, только для прототипов :)

Пока ни для каких, просто взял для тестирования такой же проект, как и у тебя.

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

А :) я для «нагрузочного» тестирования LLVM использую. Пока большего по размерам публичного проекта на CMake не нашёл. На работе был проект, но там CMake только как враппер генерился, что бы с проектом удобно было через QtC (при большом количестве таргетов Generic плагин не справляется в части адекватной настройки кодовой модели) и/или Clion работать. Получился большой: файлов около 300к, LOC около 25M. Но он только на работе :)

Кстати, тут и оказалось, что рабочий проект Clion с файлами на SSD и большем объёме памяти переваривает это безобразие почти 15 минут, а QtC под виртуалкой на HDD и 3Gb памяти тратит около минуты-полутора. Да и удобств в Clion ощутимо меньше. Вывозит парсер CMake и возможности рефакторинга (если модель не заглючила :)). KDevelop 4.6 тоже долго страдал и результат страданий получился не сильно хороший.

h4tr3d ★★★★★
()
Последнее исправление: h4tr3d (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.