Eclipse qwt

прекратить страдать херней и использовать qt-creator

прекратить страдать херней и использовать qt-creator

который, кстати, частично основан на коде эклипс-плагина :)

Я так понимаю там cpptools от туда выдернут?

Его написали, когда начали делать собственно QtC, с тех пор плагин для клипсы больше не развивался

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

Qt Creator сознательно не повторяет ошибки Eclipse, тормоза которого в основном связаны с неправильной архитектурой плагинов и необходимостью поддержания совместимости версий. В QtC ничтоже сумняшеся переделывают API между версиями чтобы сделать код чище и быстрее.

По времени решение примерно совпало со свертыванием Jambi. А если команда больше не работает с Java, то и IDE на этом языке пилить непродуктивно.

Логично, а в креаторе нет стабильного апи для плагинов, их нужно стремиться сразу в мастер контрибьютить, то есть получается аналог kernel разработки. Вот бы ещё от qmake'а уйти для полного счастья, но для этого видимо придется лично заниматься qbs плагином для креатора.

Сам qbs с нашими патчами (которые скоро в апстриме будут по видимому) уже с большей частью qutIM'а справляется, у которого не самый тривиальный процесс сборки.

Так QtCreator умеет cmake, чем не панацея?

В общем, добавление в файл *.pro нормальных путей дает возможность использовать qwt в полном объеме,

INCLUDEPATH += /usr/include/qwt-qt4
LIBS += -L/usr/lib -lqwt-qt4

однако в дизайнере форм эти возможности недоступны. Так что вопрос все еще открыт.

Язык скриптов в cmake'е это тихий ужас, который недалеко ушел от своего папаши из autolulzов. В итоге это лишь тот же autolulz но с лучшей обратной совместимостью из за cmake policy и лучшей кроссплатформенностью. язык скриптов qmake тоже имеет те же самые недостатки, но еще и не может многие фичи cmake.

qbs же на другой идеологии основан.