а не вы товарищ случаем под МСВС делали ВКС? такого гавноподелия ещё поискать. там есть VIM большего и не надо

p.s. А какое вы товарищ имеете отношение к программистам?

> Как мне представляется, это очень несложное действие

Напрасно тебе так представляется, ИМХО.

> Буду признателен за любые мысли...

Попробуй задать командой сборки проекта "ssh user@mcbc-host make" вместо обычного make (или что там в KDevelop).

== p.s. А какое вы товарищ имеете отношение к программистам? ==

Пальцы попрошу загнуть и впредь из-под плинтуса не высовываться!

== Попробуй задать командой сборки проекта "ssh user@mcbc-host make" вместо обычного make (или что там в KDevelop). ==

Это мимо кассы :) Проблема в том, что когда в KDevelop нажимаешь "Собрать проект" он вызывает что-то shellоподобное, которому передаёт ./configure и далее по тексту. Есть подозрение, что это шеллоподобное и есть системный шелл, запускаемый в каком-то внутреннем эмуляторе терминала. В рамках одной и той же ОС.

Проблема должна лечиться тем, что в дебрях KDevelop должна быть (должна, должна, это очевидно, что терминал может быть не только локальным) ссылка, что есть "терминал для KDevelop". Надо заменить в ней значение и терминалом он станет считать другое...

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

может проще на сначала на своей машине написать, а потом уже на другую портировать?

> Проблема в том, что когда в KDevelop нажимаешь "Собрать проект" он вызывает что-то shellоподобное, которому передаёт ./configure и далее по тексту

Ты хочешь сказать, что KDevelop _переконфигурирует_ проект каждый раз? Это бред, даже KDevelop не может быть таким тупым.

> В конце-концов, если есть удалённая отладка, то почему бы не быть удалённой сборке проекта?

Потому что тут всё гораздо сложнее, чем тебе кажется, и решается по-другому.

== может проще на сначала на своей машине написать, а потом уже на другую портировать? ==

Если бы такое было возможно, я бы так и сделал, а не сношался бы с этим... :( Проблема не в том, "как можно сделать ещё". Проблема в том, что компилироваться и собираться поделие должно в МСВС, а МСВС это "настоящая советская разработка" - взят некий иностранный аналог, его параметры ухудшены и изделию приданы свойства несовместимости с оригиналом. Как следствие перенос возможен не всегда и не во всём. В данном случае - никак...

== Ты хочешь сказать, что KDevelop _переконфигурирует_ проект каждый раз? Это бред, даже KDevelop не может быть таким тупым. ==

Я не утверждал этого. Я утверждал, что по внешне видимым проявлениям внутри KDevelop есть некий аналог системного терминала (консоли), в которой он, по видимому, выполняет обычный системный шелл. И в этом терминале выполняет команды, как, если бы их вводил оператор. Поэтому и мысль - терминал не должен быть монолитным, он в каком-то конфиге должен прописываться.

== Потому что тут всё гораздо сложнее, чем тебе кажется, и решается по-другому ==

А как именно это решается и в чём сложность - рассказать можешь?

>Я не утверждал этого. Я утверждал, что по внешне видимым проявлениям внутри KDevelop есть некий аналог системного терминала (консоли), в которой он, по видимому, выполняет обычный системный шелл. И в этом терминале выполняет команды, как, если бы их вводил оператор. Поэтому и мысль - терминал не должен быть монолитным, он в каком-то конфиге должен прописываться.

man popen

скорее всего через него все и делается

== man popen ==

А если так - то конфиг, в котором написано что является "внутренним шеллом" для запусков из-под KDEvelop точно где-то есть. Тем более, что если процесс сборки проекта пронаблюдать хотя бы htop'ом, то видно, что make вызвана обычным системным шеллом... В общем, надо смотреть "конфиги KDevelop" и пробовать, может, что получится...

> Я не утверждал этого.

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

> А как именно это решается

Кросс-средой. Полагаю, что ты можешь сделать отдельное дерево с либами и компиляторами МСВС (у rpm есть опция, вроде --root), и с их помощью собирать свою прогу (полагаю, архитектура хоста и таргета одна и та же?).

> и в чём сложность - рассказать можешь?

В Eclipse, например, взаимодействие Eclipse CDT с тулчейном - довольно интимый процесс :) Полагаю, что в KDevelop - та же фигня.

А в чем проблема вести разработку в нормальной системе и периодически делать порт в МСВС? Что там такого несобираемого?

== Ты сказал, что оно каждый раз запускает configure - это и есть реконфигурация. ==

ВНИМАТЕЛЬНО читаем мой исходный пост и приходим к выводу, что слова "каждый раз" ты вычитал из своей головы...

== Кросс-средой. ==

- Сэр! Не скажете ли, где мы находимся? - На воздушном шаре, господа!

== Полагаю, что в KDevelop - та же фигня. ==

А вот как бы от предположительного наклонения перейти к утверждательному?

== А в чем проблема вести разработку в нормальной системе и периодически делать порт в МСВС? Что там такого несобираемого? ==

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

> ВНИМАТЕЛЬНО читаем мой исходный пост и приходим к выводу, что слова "каждый раз" ты вычитал из своей головы...

Ты сказал: "Проблема в том, что когда в KDevelop нажимаешь "Собрать проект" он вызывает что-то shellоподобное, которому передаёт ./configure". Если это не "каждый раз", тогда что такое "каждый раз"?

>> Кросс-средой

> - Сэр! Не скажете ли, где мы находимся? - На воздушном шаре, господа!

Ну, если ты всё знаешь, не буду мешать тебе искать настройки терминала.

== Если это не "каждый раз", тогда что такое "каждый раз"? ==

А скажи пожалуйста, ты "главное" от "несущественного" отличить можешь, или тебе всё едино? В рамках поставленного вопроса "каждый раз ./configure" или "не каждый" - несущественно. Я даже больше скажу - несущественно и само ./configure - я пользуюсь qmake :))

== Ну, если ты всё знаешь, не буду мешать тебе искать настройки терминала. ==

Спасибо. Этот шаг был ожидаем с твоей стороны.

Пиши в Emacs, там есть tramp-mode (монтировать чужую файловую систему не надо для редактирования файлов) и стандартный M-x compile такие трюки позволяет, которые тебе надо. Экзампл:

http://img70.imageshack.us/img70/6238/screenshotscplisprhel4tgz8.png

> Спасибо. Этот шаг был ожидаем с твоей стороны.

Ты не понимаешь, это стандарная ситуация: те, кто kdevelop'ом пользуются, дать тебе совет по такому сложному для них вопросу не могут. А те, кто совет мог бы дать, те kdevelop'ом не пользуются.

== и стандартный M-x compile такие трюки позволяет, которые тебе надо. ==

Спасибо за наводку, но, боюсь, что оно как бы и не совсем пригодно в нашем техпроцессе. В частности, вопрос такой - Emacs позволяет иметь сравнимые с KDevelop удобства по части показать состав классов, диаграмму наследования, подвести текст реализации метода в окно при щелчке по объявлению метода?

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

== те, кто kdevelop'ом пользуются, дать тебе совет по такому сложному для них вопросу не могут. А те, кто совет мог бы дать, те kdevelop'ом не пользуются. ==

Для полноты картины мне осталось выяснить, к которому подмножеству ты причисляешь самого себя? :)

Подсказка: картинку сделал я.

== Подсказка: картинку сделал я. ==

Ну, в таком случае спасибо за помощь :) А я буду рыть дальше, потому, что перечисленные выше способности KDevelop многократно перевешивают его неспособность заменить консоль.

Уважаемый, тут люди фиксят баги по фотографиям мониторов с kernel panic'ом на них, а вы тут именно про эстетство вещаете.

Для Emacs'а есть ecb, cedet, semantic и прочая гвардия. Местный товарищ alexott успешно и много лет использует эту связку для мощного программирования на c++.

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

== Для Emacs'а есть ecb, cedet, semantic и прочая гвардия ==

Есть, и я не сомневаюсь, что это достойный инструментарий. Но сколько стоит переучить программистов работать на ней? И не одного, а всех скопом? И за один раз? Поэтому, если с КDevelop нет плавного, постепенного перехода на Emacs, то это разговор на тему, как правильно креститься - двумя перстами или щепотью... Вопрос, я напоминаю, ставился очень частный - можно ли в KDevelop заменить консоль и как это сделать.

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

Так оно так и сделано. Только это не команда "собрать и выполнить", вот в чём проблема...

да, есть еще вариант с алиасами там вообще все что душе угодно

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

Что-то я не фтыкаю о чём и как. Нельзя ли поподробнее?

Ну вот мне лень ставить 57 мб в 19 пакетах (половину кде), чтобы посмотреть, откуда там шелл дёргается. Неужто такая великая проблема найти это место, если у вас такой крутой запутанный плюсатый проект, что в него без браузера классов не залезешь?

прописать алиасы на gcc, qmake и.т.д

что такое alias и как его кушать -> в гугль

== Ну вот мне лень ставить 57 мб в 19 пакетах ==

Так а я вас, собственно, не заставляю этого делать - я обращаюсь к тем, у кого это знание лежит ближе в sysout, чем у вас :)

== Неужто такая великая проблема найти это место ==

Да нет, конечно. За неделю, так точно найдём. А, может, и быстрее - не впервой же, и не такое решали. Просто спросить проще, чем рыть, а зазорного в незнании ничего нет, зазорное в нежелании знать.

== такой крутой запутанный плюсатый проект, что в него без браузера классов не залезешь? ==

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

== что такое alias и как его кушать -> в гугль ==

Тьфу! Я-то думал, что-нибудь умное...

гм, тупее не придумаешь, в каждом учебнике по линуксу есть ))

== гм, тупее не придумаешь, в каждом учебнике по линуксу есть )) ==

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

я не считаю никого дураком, слово "тупее" я сказал относительно метода, что он простой как топор

касательно

>Однако, он имеет недостаток в том, что становится всеобщим во всей системе.

можно проверять например какой текущий каталог, и если это не каталог с вашим прожектом запускать обычный gcc, иначе shh и все что требуется

а ееще можно завести отельного юзера и пускать kdevelop из под него

s/shh/ssh

== можно проверять например какой текущий каталог, и если это не каталог с вашим прожектом запускать обычный gcc, иначе shh и все что требуется ==

Да я понимаю - как из этой ситуации _вывернуться_ я и сам могу не один способ придумать. Я же ищу ответ на прямо поставленный вопрос - как подменить консоль. Ибо чем меньше подменяется, тем больше программист может опираться на свой привычный навык и т.д. Люди со временем меняются, решения забываются, система сносится и ставится по новой и т.д. В общем, я думаю, понятно...

> Да нет, конечно. За неделю, так точно найдём. А, может, и быстрее - не впервой же, и не такое решали.

Ну народ пошёл... Project -> Project options -> Name of make executable: ssh lisp@rhel4 "cd /tmp && gcc -o sig sig.c"

http://img104.imageshack.us/img104/403/screenshotafiletmpsigcmsb0.png

тоже вариант кстати, но как быть тогда например с qmake или configure?

Сгенерировать makefile'ы можно и руками, зайдя один раз по ssh.

Уважаемые господа!

Я напоминаю исходную проблему - нет совершенно никакой проблемы в том, чтобы рядом с KDevelop иметь открытое окно SSH и в нём выполнять те консольные команды, которые и сам KDevelop выполняет через [внутреннюю] консоль. Нет никакой проблемы в том, чтобы в тулбаре определить собственные кнопки и привесить к ним команды, выполняемые через ssh.

Проблема в том, что "внутренняя консоль" прекрасно интегрирована "для чайника" - в ней и отладчик ходит, в ней и тыцнуть по сообщению можно, а редактор сам подведёт строку с ошибкой и т.д. В общем, в раскладе "сложно объяснить чайнику, что он должен делать, чтобы добиться результата" или "подменить чайнику консоль" все преимущества за подменой этой самой консоли... Чего, собственно, и ищем - где это можно сделать. Поскольку страдают же люди. Конечно, они научатся, и, возможно, и этот эпизод будет для них наукой, но всё же врождённый гуманизм заставляет меня искать, как бы это их страдание переложить на машину. Поскольку разгибание пальцов проблему не лечит вообще никак, к сожалению - они уже гнуть пробовали :)

Если кто знает - скажите, если не знает никто - мне приятно видеть глубину ваших познаний, но она не решает поставленной проблемы :(

Пока что самое конструктивное пред(по)ложение - пробежаться по возможным конфигам KDevelop и поискать там характерную строчку... Чем мы пока и займёмся. Я благодарю всех, принявших участие в обсуждении. Если мы это самое найдём и решим - я напишу, как мы это сделали.

По менюшкам в опциях найдите то, что я сказал. На второй картинке как раз щелчком по сообщению с ошибкой kdevelop на нужное место прыгнул.

Монтируешь себя на целевой машине, создаешь там директорию для сборки, находясь в ней запускаешь /директория_куда_смонтировал/configure, затем make. configure запускается один раз в начале чтобы создать директорию для сборки, дальше только make.

...Хотя если qmake то хз что можно сделать...

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

Нужно тебе шелл подменить -- пробуешь создать юзера с другим шеллом или создаешь прогу на 20 строк и втыкаешь вместо /bin/sh (хинт: если мы вне директории проекта, то exec(настоящий шелл) иначе exec(что-то другое))

Грязно и быстро.

Еще вроде есть либа для определения "из какой проги мы запущены".

Ну и наконец еще проще и разумнее те советы, которые довались -- создать алиасы (или от себя -- прописать свой путь перед запуском kdevelop, чтобы все нужные проги типа make gcc gdb... оказались скриптами)

Re^2: Как запустить SSH из-под КDevelop?

> Поделие разрабатывается на базе некоего тулкита, который непереносим... Т.е. я хотел сказать, что затраты труда по его переносу в нормальную ось совершенно неокупаемы.

Интересно, какой это такой непереносимый тулкит есть в мсвс? Там тулкитов-то в стандартной поставке раз-два и обчёлся: qt3, gtk2, tk8.3 и всё.

Или же это какая-то проприетарная быдлоподелка(tm)?

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

Это правда! Вопрос решаете вы, уважаемые господа, я всего-лишь заинтересован в узнавании некоторого спектра мнений, укладывающихся в заданный телесный угол. Мне совершенно не нужна ситуация, когда таких мнений будет или ни одного или ровно одно "абсолютно правильное". Но и выйти за пределы того телесного угла, что обозначен, мне тоже крайне затруднительно - есть технология, есть конкретно заточенные люди, экономика, наконец... Начни этот проект сначала, то я, конечно, некоторые вещи в нём делал бы теперь совершенно не так :)))

== Или же это какая-то проприетарная быдлоподелка(tm)? ==

Она самая :(((( Если учесть, что и сама МСВС это глубоко советское изделие (выше я писал об этом), то приходится признать, что отрасль индустрии "производство программ для ЭВМ" глубоко деградировала в постсоветской России... Она и в советской-то не отличалась, но сейчас, по-моему, уже полный капут.

> сама МСВС это глубоко советское изделие (выше я писал об этом)

В советские времена не существовало red hat linux, с которого перепёрт мсвс, так что не надо тут гнать на советских программистов :)

Выражаю свои соболезнования. Особенно в связи с тем, что ещё сильным геморроем будет подключить удалённую отладку в kdevelop.

Кстати, почему бы не скомпилить kdevelop под мсвс b yt pfgecnbnm tuj jnnelf? qt3 там имеется, gcc тоже.

> b yt pfgecnbnm tuj jnnelf?

перевод с арктурианского: "и не запустить его оттуда?"