Не я все типа понимаю — и опенсорс и беспланый, и все такое...
Но среда ИМХА такая сырая, что просто атас, то всем при том, выглядит как полная замена студии.

Вот столкнулся: https://bugs.eclipse.org/bugs/show_bug.cgi?id=157220

1)Имеем некий кросплатформенный тусчайн С++.
2)Имеем проект кода очень большой. Собирается простым мэком. Лазить по буилд логу ну очень достает. Дай думаю возьму Эклипс и пусть сам ошибки пасрсит, за одно и редактор.
3)В проекте есть несколько библиотек для разных "вариантов" сборки. В этих библиотеках есть одинаковые файлы. Ну скажем printf.c.
4) Запускаю сборку — и вижу что большая часть ошибок GCC парсится нормально, а некоторые ну никак. Делаю свой регекс на парсер ошибок. Все равно выдает вместо файла — просто имя проекта.
5) Беру и просто в отдельный регексп вбиваю 100% текста ошибки, а в имя файла вбиваю тупо имя printf.c. CDT его отлично отдельно находит. Но опять нет навигации по коду, вместо имени файла опять просто имя проекта.
6) Беру и для этого регекспа тупо вбиваю ДРУГОЙ файл (который один в проекте) — И... Тадада — и навигация заработала, и имя проявилось.

Вопрос — 2006 год факт фиксации ошибки, сейчас 2016. А конь и ныне там.
Вот вам и линуксовые продукты. Даже если они номинально есть — то они нихрена не работают.
Блин. !)

Здравствуйте, Andrew.W Worobow, Вы писали:

AWW>Вот столкнулся: https://bugs.eclipse.org/bugs/show_bug.cgi?id=157220

Там Алена ведь написала внизу совет. Use full file name to set breakpoints

AWW>Вопрос — 2006 год факт фиксации ошибки, сейчас 2016. А конь и ныне там.

Значит community эта проблема не казалась важной.

AWW>Вот вам и линуксовые продукты. Даже если они номинально есть — то они нихрена не работают.

Eclipse — не линуксовый продукт. Более того, твоя проблема относится к CDT а не Eclipse-у как базовой платформе.

AWW>Блин. !)

Берешь сорцы и пробуешь фиксить сам, если нужен фикс.

Нынче Эклипсом занимаются в основном индусы, потому и рез-ты соответствующие.

Здравствуйте, sergey179, Вы писали:

S>Значит community эта проблема не казалась важной.
https://bugreports.qt.io/browse/QTBUG-16443
Path too long слышали проблему? 2011 год. До сих пор не пофикшено. Ага, комьюнете это не важно. Знакомая мантра..

Здравствуйте, Vain, Вы писали:

V>https://bugreports.qt.io/browse/QTBUG-16443
V>Path too long слышали проблему? 2011 год. До сих пор не пофикшено. Ага, комьюнете это не важно. Знакомая мантра..

Кстати, да! MSVC задрала с этой проблемой, с её 260 символов на путь. Из-за этого пришлось исходники переименовывать и папки, давать имена из буквенных аббревиатур, чтобы под Виндой проект компилировался.

Здравствуйте, Nuzhny, Вы писали:

V>>https://bugreports.qt.io/browse/QTBUG-16443
V>>Path too long слышали проблему? 2011 год. До сих пор не пофикшено. Ага, комьюнете это не важно. Знакомая мантра..
N>Кстати, да! MSVC задрала с этой проблемой, с её 260 символов на путь. Из-за этого пришлось исходники переименовывать и папки, давать имена из буквенных аббревиатур, чтобы под Виндой проект компилировался.
Самое интересное что кутешники без мсвс могли это исправить, но забили. Патч там прилагается.