execve wrote:

> C>У меня куча библиотек в h-файлах. Где автоматическое вычисление
> C>зависимостей? То есть, если я меняю файлик grammar.hpp, то мне НЕ
> C>хочется перекомпилировать все cpp-шники, а только те, где включен
> C>grammar.hpp. При этом еще желательно, чтобы автоматически определялись
> C>non-relevant изменения (то есть, если файл blah.cpp только включает
> C>grammar.hpp, но не использует его — то перекомпилировать его не надо).
> http://www.rsdn.ru/Forum/Message.aspx?mid=1296922&only=1

Автор: execve
Дата: 28.07.05

> <http://rsdn.ru/Forum/Message.aspx?mid=1296922&amp;only=1&gt;

Автор: execve
Дата: 28.07.05

Вы представляете, сколько это будет работать на библиотеке типа Boost'а?
Да еще и работает это все неикрементально (в отличие от VS) (которая
отслеживает изменения в include'ах).

> C>Почему линковка не инкрементальная?
> Почему в шапке?

Ну знаете, у меня в проекте полная линковка занимает две минуты, а
инкрементальная — всего 30 секунд.

> C>Да, забыл сказать, что под _нормальным_ отладчиком. То есть с
> нормальным
> C>интерфейсом, а не командной строкой.
>
>$ ddd ./1
>
>
Плоховато у него с нафигацией по коду.

> C>Про edit&continue я вообще молчу...
> Правильно молчишь.

Ну да, в Linux'е его нет — значит это ересь. Слышали уже....

--
С уважением,
Alex Besogonov (alexy@izh.com)

C>Значит, class browser таки используется. Только в виде внешней утилиты,
C>которая на сложном С++ весьма глючная.

Примеры глюков Doxygen?

А можно и так:

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

dmz>http://www.opennet.ru/docs/RUS/gnumake/index.html
dmz>autotools

C>>>Далее, у меня исходники раскиданы по достаточно глубокому дереву
C>>>каталогов. Где здесь рекурсивный обход?

E>>

E>>OBJ=`find . -name "*.cc" | sed 's/\(.*\)\.cc/\1.o/'`
E>>

dmz>Прикольно. Но можно и средствами GNU make.
dmz>

dmz>    program_name := iEdit
dmz>    source_dirs  := . Editor TextLine 
dmz>    include_dirs := /c/aproj/lib  /c/aproj/lib/linux
dmz>    link_flags   := -static 
    
dmz>    source_dirs  := $(addprefix ../../src/, $(source_dirs) )
dmz>    source_files := $(wildcard $(addsuffix /*.cpp, $(source_dirs) ) )
dmz>    object_files := $(notdir $(source_files) )
dmz>    object_files := $(object_files:.cpp=.o)
    
dmz>    $(program_name): $(object_files)
dmz>        gcc $^ -o $@ $(link_flags) -pipe 
        
dmz>    VPATH := $(source_dirs)
    
dmz>    %.o: %.cpp 
dmz>        gcc $< -c $(compile_flags) $(addprefix -I, $(include_dirs)) $(addprefix -I, $(source_dirs)) -MD -pipe 2>log
    
dmz>    include $(wildcard *.d) 
dmz>

А еще лучше средствами MPC, CMake, SCons или Mxx_ru

C>Ну да, в Linux'е его нет — значит это ересь. Слышали уже....
Система открытая и бесплатная. Вам что-то надо, а этого нет —
допишите. Ну или хотя бы фиче-реквест отправьте куда надо.

Вот не пойму — оно всё вам надо или нет? Если да — то есть два
пути: научиться пользоваться тем, что есть или написать своё.

Что толку от разведения тут базара? От него что, волшебным образом
ваше любимое MSVS в линукс портируется, что ли?

Знаю кучу людей, которым удобно работать именно так, как вам упорно не
нравится. То, что все такое, какое оно есть означает ровно то,
что тем кто разрабатывает под GNU, работать удобно именно так.

Извините, интересы MS разработчиков они не учли.

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

C>execve wrote:

>> <http://rsdn.ru/Forum/Message.aspx?mid=1296922&amp;only=1&gt;

Автор: execve
Дата: 28.07.05

C>Вы представляете, сколько это будет работать на библиотеке типа Boost'а?

Простите, вы boost отлаживаете?
Если да, то один раз make depend.
Если нет, то зачем учитывать зависимости от boost'а?

C>Да еще и работает это все неикрементально (в отличие от VS) (которая
C>отслеживает изменения в include'ах).

Оно отслеживает изменение в include'ах.

C>Ну знаете, у меня в проекте полная линковка занимает две минуты, а
C>инкрементальная — всего 30 секунд.

А у меня ещё меньше.
Потому, что есть разделение на библиотеки.

>>$ ddd ./1
>>
C>Плоховато у него с нафигацией по коду.

Меня устраивает.
А если тебе нужно "то же самое, но с перламутровыми пуговицами" — ищи сам:

$ apt-cache search debugger | wc -l
160

>> C>Про edit&continue я вообще молчу...
>> Правильно молчишь.

C>Ну да, в Linux'е его нет — значит это ересь. Слышали уже....

См. выше про библиотеки.

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

C>Все, достало. Четыре дня убил на настройку Emacs'а, а конца ей не видно.

Прочитал весь тред.
Резюме одно: "со своим уставом в чужой монастырь не ходят".

Все твои претензии — суть "я в Windows/VisualStudio привык делать ТАК, как мне сделать ТОЧНО ТАК ЖЕ в Linux/Whatever".

Тебе-таки процесс нужен, или результат?
Если процесс, то боюсь, ни [X]Emacs, ни остальное тебе не поможет. Просто потому, что под *nix нет Visual Studio.
Если результат, то придётся-таки изучить те методы достижения результатов, которые приняты в *nix. Они не лучше и не хуже, чем в Visual Studio, они просто другие.

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

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

J>>Сколько-сколько??????? Это у нас сейчас называется мало?

BQS>По PCшным меркам, в общем-то, да. Какой у вас винчестер? 20? 10? 5? Даже если 5, то 300 Мб — это мало.

Ну да, я забыл, ведь память у нас больше не русурс...

Повторю, для меня 300 МБ ради тупой возможности редактировать жаверские файлы — это очень много.
Потому что, повторю, у меня есть чем винт забить, намного более полезным и для меня нужным.
Если у вас такого нет и единственное, чем можно заполнить винт — это очереджной редактор на 300 метров — я очень за вас рад, но это не мой случай.

You will always get what you always got
  If you always do  what you always did

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

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

ME>>>Если человек не умеет пользоваться ручной коробкой передач, значит ли это, что все машины с такой коробкой неюзабельны?

J>>Вообще говоря, ручная коробка передач, с которой человек не в состоянии освоиться за 4 дня — это неюзабельная коробка передач :)

BQS>Вообще говоря, реактивный истребитель, с которым человек не в состоянии справиться за четыре дня, совершенно необязательно является неюзабельным истребителем. Более того, этот факт не скажет о юзабельности истребителя НИ-ЧЕ-ГО.

А с чем Вы спорите, собственно?
Максим, который не я, говорил о ручной коробке передач, и я ему возразил.Вот если бы он говорил про реактивный истребитель — я бы возражал ему иначе, а именно: если редактор сравним по сложности с реактивным истребителем, то это — неправильный редактор, потому что редактор должен быть сравним по сложности с коробкой-автомат, максимум — с ручной. Потому что редактор — это вспомогтельное средство и не более того, и ресурсов спинного мозга на него должно хватать с головой, потому что голова должна быть занята делом, а не многочисленными трех-четырехклавишными шорткатами и прочими неочевидными настройками.

You will always get what you always got
  If you always do  what you always did

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

J>Если у вас такого нет и единственное, чем можно заполнить винт — это очереджной редактор на 300 метров — я очень за вас рад, но это не мой случай.

Это вы мне говорите, да?

jazzer wrote:

> BQS>По PCшным меркам, в общем-то, да. Какой у вас винчестер? 20? 10?
> 5? Даже если 5, то 300 Мб — это мало.
> Ну да, я забыл, ведь память у нас больше не русурс...
> Повторю, для меня 300 МБ ради тупой возможности редактировать
> жаверские файлы — это очень много.

Если необходимость писать программы на Java — одна из основных
потребностей, то тут лишние 300Мб ничего не значат. А если просто
изредка нужно что-то подредактировать, то вполне подойдет jEdit или даже
встроеный редактор FARа. Для FARа можно даже умный autocomplete для Java
поставить (плугин такой есть).

> Потому что, повторю, у меня есть чем винт забить, намного более
> полезным и для меня нужным.
> Если у вас такого нет и единственное, чем можно заполнить винт — это
> очереджной редактор на 300 метров — я очень за вас рад, но это не мой
> случай.

IDEA/Eclipse — это не _редакторы_, а IDE. Две большие разницы, что
называется.

--
С уважением,
Alex Besogonov (alexy@izh.com)

execve wrote:

> C>Все, достало. Четыре дня убил на настройку Emacs'а, а конца ей не видно.
> Прочитал весь тред.
> Резюме одно: "со своим уставом в чужой монастырь не ходят".
> Все твои претензии — суть "я в Windows/VisualStudio привык делать ТАК,
> как мне сделать ТОЧНО ТАК ЖЕ в Linux/Whatever".

Проблема в том, что сейчас есть де-факто стандарты на IDE.

> Тебе-таки процесс нужен, или результат?

И то, и другое.

> Если процесс, то боюсь, ни [X]Emacs, ни остальное тебе не поможет.
> Просто потому, что под *nix нет Visual Studio.

Да, к сожалению для С++ в *nix'ах нет VS. В основном из-за большой
сложности самого языка С++. А вот для Java/Python/C#/Perl аналоги VS
вполне себе существуют и чувствуют себя неплохо.

> Если результат, то придётся-таки изучить те методы достижения
> результатов, которые приняты в *nix. Они не лучше и не хуже, чем в
> Visual Studio, они просто другие.

Я сейчас вижу, что они заставляют меня писать кучу скриптов, рыться в
горах настроек, а результаты получаются не лучше, чем в VS.

--
С уважением,
Alex Besogonov (alexy@izh.com)

C>Да, к сожалению для С++ в *nix'ах нет VS. В основном из-за большой
C>сложности самого языка С++. А вот для Java/Python/C#/Perl аналоги VS
C>вполне себе существуют и чувствуют себя неплохо.

Это вы, наверное, с ними плотно не работали.
Что-то мне все равно подсказывает, что все равно 90% кода на скриптовых
языках пишется и правится в vim/emacs. Потому что проще и удобнее, плюс
сами языки довольно емкие — писанины меньше получается. К Java и C# это, конечно,
не относится.


C>Я сейчас вижу, что они заставляют меня писать кучу скриптов, рыться в
C>горах настроек, а результаты получаются не лучше, чем в VS.

Настройка редактора под свой вкус и стиль работы — это разовая акция.
Делается один раз за всю жизнь, после чего конфиг может спокойно
перетаскиваться с одного рабочего места на другое. Тоже относится к
autotools и/или написанию мейкфайла. Но и эту акцию можно ускорить,
если воспользоваться готовыми конфигами, которые постепенно
подкрутить под себя. В принципе, мы уже в этом топике потратили больше
времени, чем нужно для того, что бы достичь желаемой цели — получить
приемлемую среду для разработки.

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

C>Проблема в том, что сейчас есть де-факто стандарты на IDE.
Это вам так кажется, просто. Что они есть. Они есть только для
представителей альтернативной, околовиндузовой реальности

Но, с другой стороны, никто же не мешает написать свою IDE, учитывая
эти "стандарты". Можно даже заточить под них готовую — тот же KDevelop.
Чего там не хватало-то? Если эти идеи востребованы, то прославитесь.

dmz wrote:

> C>Проблема в том, что сейчас есть де-факто стандарты на IDE.
> Это вам так кажется, просто. Что они есть. Они есть только для
> представителей альтернативной, околовиндузовой реальности

Простите, эта "альтернативная" реальность занимает процентов 95% рынка,
так что альтернативная реальность — это emacs/vim. А причина —
производители IDE думают об удобстве пользователя, наравне с
функциональностью.

> Но, с другой стороны, никто же не мешает написать свою IDE, учитывая
> эти "стандарты". Можно даже заточить под них готовую — тот же KDevelop.
> Чего там не хватало-то? Если эти идеи востребованы, то прославитесь.

Подбросил коллегам идею прикрутить xrefactory к Eclipse CDT. Так что все
возможно...

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Простите, эта "альтернативная" реальность занимает процентов 95% рынка,
C>так что альтернативная реальность — это emacs/vim. А причина —
C>производители IDE думают об удобстве пользователя, наравне с
C>функциональностью.

Десктопов, не забывайте добавлять.

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

C>Проблема в том, что сейчас есть де-факто стандарты на IDE.

VS никоим местом не стандарт, даже де-факто.

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

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

J>>Если у вас такого нет и единственное, чем можно заполнить винт — это очереджной редактор на 300 метров — я очень за вас рад, но это не мой случай.

BQS>Это вы мне говорите, да? ;)

Ну так о чем мы тогда спорим??? :)
P.S. Stiv Vai -> Steve Vai :)

You will always get what you always got
  If you always do  what you always did

Quintanar wrote:

> C>Проблема в том, что сейчас есть де-факто стандарты на IDE.
> VS никоим местом не стандарт, даже де-факто.

Я не про VS говорю, а про общие принципы создания современных IDE. В
частности, они подразумевают использование понятия "проектов",
современные IDE предоставляют пользователю удобную навигацию по дереву
проекта, tabbed MDI интерфейс, удобные (и достаточно стандартные) меню.
Так же, считается хорошим тоном иметь встроеный отладчик и некоторы
интегрированые инструменты.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

C>>В C++ в одном файле могут быть несколько классов. Как мне быстро найти,
C>>где определен данный класс? Еще часто очень удобно посмотреть какие у
C>>класса есть наследники и предки.

E>doxygen мне в этом очень помогает.

а он отслеживает, какие файлы изменились, с тем, чтобы перепарсить только их?
Или он каждый раз заново парсит всю тучу файлов проекта?

You will always get what you always got
  If you always do  what you always did

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

C>execve wrote:

>> C>Все, достало. Четыре дня убил на настройку Emacs'а, а конца ей не видно.
>> Прочитал весь тред.
>> Резюме одно: "со своим уставом в чужой монастырь не ходят".
>> Все твои претензии — суть "я в Windows/VisualStudio привык делать ТАК,
>> как мне сделать ТОЧНО ТАК ЖЕ в Linux/Whatever".

C>Проблема в том, что сейчас есть де-факто стандарты на IDE.

Для разработчиков под Windows.
Остальное комментировать не буду, так как все проблемы — от этого.