[Comm] Packages for C/C++

[Comm] Packages for C/C++

[Andrey Rybak]

Всем привет!
Я - программирую на С/С++. Но с Линукс знаком очень недавно. Подскажите, 
пожалуйста, имена всех пакетов которые необходимы для полнокровной 
работы с этими языками программирования.

Re: [Comm] Packages for C/C++

[vic ismakaev]

28 Апрель 2003 16:12, Andrey Rybak написал:
> Всем привет!
> Я - программирую на С/С++. Но с Линукс знаком очень недавно. Подскажите,
> пожалуйста, имена всех пакетов которые необходимы для полнокровной
> работы с этими языками программирования.
Что Вам нужно для полнокровной работы - трудно сказать :)
А для начала 
apt-get install rpm-build подтянет gcc,make,autoconf
 anjuta,kdevelop,vim,emacs - среды разработки
в ххх-devel.rpm  лежат библиотеки и хедеры для разработки с использованием 
соответсвующих прог/либ. 
-- 
С уважением
Виктор В Исмакаев

Re: [Comm] Packages for C/C++

[Andrey Rybak]

vic ismakaev wrote:

>28 Апрель 2003 16:12, Andrey Rybak написал:
>  
>
>>Всем привет!
>>Я - программирую на С/С++. Но с Линукс знаком очень недавно. Подскажите,
>>пожалуйста, имена всех пакетов которые необходимы для полнокровной
>>работы с этими языками программирования.
>>    
>>
>Что Вам нужно для полнокровной работы - трудно сказать :)
>А для начала 
>apt-get install rpm-build подтянет gcc,make,autoconf
> anjuta,kdevelop,vim,emacs - среды разработки
>в ххх-devel.rpm  лежат библиотеки и хедеры для разработки с использованием 
>соответсвующих прог/либ. 
>  
>
Хорошо, это, конечно, работает. Но у меня сразу возник следующий вопрос. 
Возможно эта импровизация некорректна, но назовем в Вашем ответе на 
вышестоящий вопрос rpm-build "корневым пакетом" для работы с языками 
С/С++. Как я мог бы стандартными средствами Линукса узнать, что является 
"корневым пакетом" для моей какой-то задачи, т.е. как бы я узнал о 
существовании rpm-build самостоятельно? Конструкция типа apt-cach search 
c++ не подходит для этой цели, так как выбрасывает много пакетов и 
откуда мне знать, какие мне действительно нужны? И не обязательно эта 
команда выбросит _все_ нужные пакеты. Вобщем, давайте проведем 
инсталляцию ,к примеру, всего необходимого для минимальной работы PHP. В 
свете всего вышесказанного. Надеюсь, этот важный, я думаю, вопрос 
прозвучал достаточно ясно (и убедительно).

Re: [Comm] Packages for C/C++

[Andrey Rybak]

Vitaly Lugovsky wrote:

>On Sat, 3 May 2003, Andrey Rybak wrote:
>
>  
>
>>Хорошо, это, конечно, работает. Но у меня сразу возник
>>следующий вопрос.  Возможно эта импровизация некорректна, но
>>назовем в Вашем ответе на вышестоящий вопрос rpm-build
>>"корневым пакетом" для работы с языками С/С++.
>>    
>>
>
> Нет. Это "корневой пакет" для сборки некоторого подмножества
>стандартных пакетов. Не более того.
>
>  
>
>>Как я мог бы стандартными средствами Линукса узнать, что
>>является "корневым пакетом" для моей какой-то задачи, т.е. как
>>бы я узнал о существовании rpm-build самостоятельно?
>>Конструкция типа apt-cach search c++ не подходит для этой цели,
>>так как выбрасывает много пакетов и откуда мне знать, какие мне
>>действительно нужны?
>>    
>>
>
> А если ты не знаешь, что тебе нужно, то лучше бы и не брался
>за столь нелепое для непрофессионала занятие, как
>"программирование" на C/C++. Надо сначала собственно
>программировать научиться, привить себе правильную культуру
>пользования компутером, и т.п. Правда, после этого от С/C++
>рвотный рефлекс стабильно пробуждаться будет, ну да для
>профессионала это не помеха.
>
>  
>
>>И не обязательно эта команда выбросит
>>_все_ нужные пакеты. Вобщем, давайте проведем инсталляцию ,к
>>примеру, всего необходимого для минимальной работы PHP. В свете
>>всего вышесказанного. Надеюсь, этот важный, я думаю, вопрос
>>прозвучал достаточно ясно (и убедительно).
>>    
>>
>
> А вот тут apt-cache search php хватит выше крыши.
>
> Кроме того, есть synaptic, позволяющий бровзить пакетики по
>группам.
>
>  
>
PHP - это только пример. apt-cache search php в данном случае и 
достаточно, а вот что вы скажете по поводу ruby или emacs. (И, 
опять-таки, это только пример!). Поэтому возможность поиска "корневых 
пакетов" Д.Б. ИМХО.

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Sat, 3 May 2003, Andrey Rybak wrote:

> Хорошо, это, конечно, работает. Но у меня сразу возник
> следующий вопрос.  Возможно эта импровизация некорректна, но
> назовем в Вашем ответе на вышестоящий вопрос rpm-build
> "корневым пакетом" для работы с языками С/С++.

 Нет. Это "корневой пакет" для сборки некоторого подмножества
стандартных пакетов. Не более того.

> Как я мог бы стандартными средствами Линукса узнать, что
> является "корневым пакетом" для моей какой-то задачи, т.е. как
> бы я узнал о существовании rpm-build самостоятельно?
> Конструкция типа apt-cach search c++ не подходит для этой цели,
> так как выбрасывает много пакетов и откуда мне знать, какие мне
> действительно нужны?

 А если ты не знаешь, что тебе нужно, то лучше бы и не брался
за столь нелепое для непрофессионала занятие, как
"программирование" на C/C++. Надо сначала собственно
программировать научиться, привить себе правильную культуру
пользования компутером, и т.п. Правда, после этого от С/C++
рвотный рефлекс стабильно пробуждаться будет, ну да для
профессионала это не помеха.

> И не обязательно эта команда выбросит
> _все_ нужные пакеты. Вобщем, давайте проведем инсталляцию ,к
> примеру, всего необходимого для минимальной работы PHP. В свете
> всего вышесказанного. Надеюсь, этот важный, я думаю, вопрос
> прозвучал достаточно ясно (и убедительно).

 А вот тут apt-cache search php хватит выше крыши.

 Кроме того, есть synaptic, позволяющий бровзить пакетики по
группам.

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Sat, 3 May 2003, Andrey Rybak wrote:

> PHP - это только пример. apt-cache search php в данном случае
> и достаточно, а вот что вы скажете по поводу ruby или emacs.

 И тут тоже apt-cache search или просмотр соответствующих групп
в synaptic - достаточны.

> (И,
> опять-таки, это только пример!). Поэтому возможность поиска
> "корневых  пакетов" Д.Б. ИМХО.

 Ви таки будете совсем смеяться, но нет их, "корневых пакетов".
Совсем нет. Только для некоторых частных случаев вроде "всё KDE".

 И лично я, к примеру, таки и не буду делать пакет вроде "Ocaml и
все библиотеки", или "Всё для Haskell". Ибо не надо. Ставить надо
только то, что реально используешь.

 Вот тот же C++ - что, к нему и BOOST весь ставить, и всякие там
doxygen-ы мелкой россыпью? Дык эта, передняя морда лица на
трещины изойдёт...

Re: [Comm] Packages for C/C++

[Andrey Rybak]

vic ismakaev wrote:

>28 Апрель 2003 16:12, Andrey Rybak написал:
>  
>
>>Всем привет!
>>Я - программирую на С/С++. Но с Линукс знаком очень недавно. Подскажите,
>>пожалуйста, имена всех пакетов которые необходимы для полнокровной
>>работы с этими языками программирования.
>>    
>>
>Что Вам нужно для полнокровной работы - трудно сказать :)
>А для начала 
>apt-get install rpm-build подтянет gcc,make,autoconf
> anjuta,kdevelop,vim,emacs - среды разработки
>в ххх-devel.rpm  лежат библиотеки и хедеры для разработки с использованием 
>соответсвующих прог/либ.
>
apt-get install rpm-build,
а затем
apt-get install kdevelop
сработало там где я инсталлировал с дисков Junior.
А вот при попытке apt-get install kdevelop (на другой машине)по сети выдется следующее:

Reading Package Lists... Done
Collecting File Provides... Done
Building Dependency Tree... Done
Package kdevelop has no available version, but exists in the database.
This typically means that the package was mentioned in a dependency and
never uploaded, has been obsoleted or is not available with the contents
of sources.list

Как выйти из этой ситуации?

> 
>  
>

Re: [Comm] Packages for C/C++

[Alexander Dymo]

>  kdevelop для разработки на C/C++ не нужен.
Ой, еще как нужен ;).
Всем, кому нужен, смотреть только на версию 3.0. Ветке 2.х третий год пошел,
а она все без изменений :)

>  Да и вообще, он вечно сырой.
Над этим работаем...

-- 
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department
KDevelop, KOffice developer

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Mon, 5 May 2003, Andrey Rybak wrote:

> apt-get install kdevelop

 kdevelop для разработки на C/C++ не нужен.

 Да и вообще, он вечно сырой.

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Mon, 5 May 2003, Alexander Dymo wrote:

> >  kdevelop для разработки на C/C++ не нужен.
> Ой, еще как нужен ;).

 Тогда такие разработчики не нужны, кому он нужен. Я серьёзно.

> Всем, кому нужен, смотреть только на версию 3.0. Ветке 2.х
> третий год пошел, а она все без изменений :)

 Смотрел. Такое же малофункциональное глюкало. Удивительно, как
народ может столько лет ходить по одним и тем же граблям...

> >  Да и вообще, он вечно сырой.
> Над этим работаем...

 Пока безрезультатно, увы. Всем, кто спрашивает про IDE, я пока
вынужден советовать emacs. Пусть непривычно, но пока альтернативы
нет. KDevelop предполагался как нечто среднее между двумя мирами
- миром виндоламеров, и миром Unix Way - но пока что сильный крен
в сторону ламерства перевешивает, что весьма таки обидно - идея
была хорошая.

Re: [Comm] Packages for C/C++

[Alexander Dymo]

On Tuesday 06 May 2003 22:40, Vitaly Lugovsky wrote:
> > Всем, кому нужен, смотреть только на версию 3.0. Ветке 2.х
> > третий год пошел, а она все без изменений :)
>
>  Смотрел. Такое же малофункциональное глюкало. Удивительно, как
> народ может столько лет ходить по одним и тем же граблям...
Неверно! Возьмите cvs snapshot и взгляните на количество поддерживаемых
языков, превосходную поддержку с++ (problem reporter, new class wizard,
qt-ui subclassing, code completion, class viewer, etc.). Во 2-м такого вообще
не было.

> > >  Да и вообще, он вечно сырой.
> >
> > Над этим работаем...
>
>  Пока безрезультатно, увы.
Будьте благосклонней ;), до релиза еще далеко. Релиз будет одновременно с
KDE3.2 Но как для alpha то стабильность потрясающая.

> Всем, кто спрашивает про IDE, я пока
> вынужден советовать emacs. Пусть непривычно, но пока альтернативы
> нет.
emacs - не IDE. Это _редактор_. Хотя не возражаю, что с помощью такого
великолепного редактора можно горы воротить.

>  KDevelop предполагался как нечто среднее между двумя мирами
> - миром виндоламеров, и миром Unix Way - но пока что сильный крен
> в сторону ламерства перевешивает, что весьма таки обидно - идея
> была хорошая.

Да где же это там крен в сторону ламерства, позвольте узнать? 
Кстати о Unix Way, kdevelop сейчас объединяет в единой оболочке все те
же знакомые средства - autotools, qmake, doxygen, valgrind, gdb ... И в
отличие от версии 2.х интеграция с autotools намного лучше (сообщение 
"KDevelop will overwrite this part" в makefile.am, например, кануло в Лету).
Основная идея kdevelop3 - обеспечить _эффективную_ работу с имеющимися
инструментами, а в особенности с qt/KDE - oriented (qt designer, qmake).
И именно это я считаю признаком хорошей IDE. А что касается текстового
редактора, то у kdevelop его вообще теперь нет! На выбор - kate, qeditor,
vim (gvim, kvim), nedit.
Насчет идей, подкиньте новые, хорошие. 

PS: может кто напишет KDE-шную интеграцию для emacs подобно тому как
это сделано для vim.

-- 
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Tue, 6 May 2003, Alexander Dymo wrote:

> > > Всем, кому нужен, смотреть только на версию 3.0. Ветке 2.х
> > > третий год пошел, а она все без изменений :)
> >
> >  Смотрел. Такое же малофункциональное глюкало. Удивительно, как
> > народ может столько лет ходить по одним и тем же граблям...
> Неверно! Возьмите cvs snapshot и взгляните на количество
> поддерживаемых
> языков, превосходную поддержку с++ (problem reporter, new
> class wizard,
> qt-ui subclassing, code completion, class viewer, etc.). Во
> 2-м такого вообще не было.

 Ок, поглядим. Последняя версия, которую я смотрел - была из
Дедала...

> > > >  Да и вообще, он вечно сырой.
> > >
> > > Над этим работаем...
> >
> >  Пока безрезультатно, увы.
> Будьте благосклонней ;), до релиза еще далеко. Релиз будет
> одновременно с
> KDE3.2 Но как для alpha то стабильность потрясающая.

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

> > Всем, кто спрашивает про IDE, я пока
> > вынужден советовать emacs. Пусть непривычно, но пока альтернативы
> > нет.
> emacs - не IDE. Это _редактор_.

 Таки нет. Это именно IDE. С небольшим таким простеньким
встроенным редактором.

> >  KDevelop предполагался как нечто среднее между двумя мирами
> > - миром виндоламеров, и миром Unix Way - но пока что сильный крен
> > в сторону ламерства перевешивает, что весьма таки обидно - идея
> > была хорошая.
>
> Да где же это там крен в сторону ламерства, позвольте узнать?

 Нет нормальной возможности заскриптовать всё, что угодно. То
самое, чем Emacs давить всех потенциальных конкурентов.

 Ну и внешний вид уж больно неприятные ассоциации с MSVS
вызывает.

> Кстати о Unix Way, kdevelop сейчас объединяет в единой
> оболочке все те же знакомые средства - autotools, qmake, doxygen, valgrind,
> gdb ...

 Всё это замечательно... Вот только вшиты они уж больно железно.
Что есть серьёзное отступление от Unix Way...

> И в отличие от версии 2.х интеграция с autotools намного лучше
> (сообщение "KDevelop will overwrite this part" в makefile.am,
> например, кануло в Лету). Основная идея kdevelop3 - обеспечить
> _эффективную_ работу с имеющимися инструментами, а в
> особенности с qt/KDE - oriented (qt designer, qmake). И именно
> это я считаю признаком хорошей IDE.

 Для меня хорошая IDE - неограниченно настраиваемая IDE. Пока же
мне выкручивают руки, навязывая какие-то конкретные инструменты и
способы их применения - я избегаю использовать такую IDE.

> А что касается текстового редактора, то у kdevelop его вообще
> теперь нет! На выбор - kate, qeditor, vim (gvim, kvim), nedit.
> Насчет идей, подкиньте новые, хорошие.

 Редактор - самая незначительная часть любой IDE.

 А идея одна, Unix Way зовётся. Вкрутить в KDevelop guile или
Питона, дать скриптам доступ ко всем потрохам KDevelop - и тогда
получится замечательная IDE. Но при нынешней его архитектуре это
задача крайне сложная. Лично я бы за такую ни за что не взялся.

Re: [Comm] Packages for C/C++

[Alexander Dymo]

On Tuesday 06 May 2003 23:50, Vitaly Lugovsky wrote:
>  А идея одна, Unix Way зовётся. Вкрутить в KDevelop guile или
> Питона, дать скриптам доступ ко всем потрохам KDevelop - и тогда
> получится замечательная IDE. Но при нынешней его архитектуре это
> задача крайне сложная. Лично я бы за такую ни за что не взялся.

ls kdevelop/parts/scripting
kdevelop.py            scriptingpart.cpp  init.py  kdevscripting.desktop  
Makefile.am  pydcopc.cpp  pydcop.py   scriptingpart.h

cd kdevelop/parts/scripting
du -a
4       ./Makefile.am
4       ./init.py
4       ./kdevelop.py
4       ./kdevscripting.desktop
12      ./pydcop.py
20      ./pydcopc.cpp
8       ./scriptingpart.cpp
4       ./scriptingpart.h

Задача на "вкручивание" python уже решена! Причем легко и просто.
И, кстати, именно архитектура позволит довести скриптование до
надлежащего уровня. Все, что требуется - это DCOP интерфейсы
для всех компонент KDevelop (сейчас есть для cppsupport, filter - обработка
вывода скриптов, sourceinfo - хранилище классов, методов и т.д., для всех
"core components").

PS: вообще используя dcoppython задачу интеграции python + любая KDE программа
можно решить за пару дней. В пакете kdebindings есть также dcopperl, но,
насколько я знаю, его пока никто не использует. Для guile подобного
не видел.

-- 
Alexander Dymo
Ukrainian State Maritime Technical University, IT Department

Re: [Comm] Packages for C/C++

[Vitaly Lugovsky]

On Wed, 7 May 2003, Alexander Dymo wrote:

> >  А идея одна, Unix Way зовётся. Вкрутить в KDevelop guile или
> > Питона, дать скриптам доступ ко всем потрохам KDevelop - и тогда
> > получится замечательная IDE. Но при нынешней его архитектуре это
> > задача крайне сложная. Лично я бы за такую ни за что не взялся.
>
> ls kdevelop/parts/scripting
> kdevelop.py            scriptingpart.cpp  init.py
> kdevscripting.desktop
> Makefile.am  pydcopc.cpp  pydcop.py   scriptingpart.h

 ...

 Это я видел... Маловато будет. :(

 Но тоже неплохо, сразу делает KDevelop много лучше чем всякие
там Eclipse.