LINUX.ORG.RU

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


0

0

Вопрос следующий. Есть небольшая целевая машина под МСВС. И есть нормальная машина разработчика. Программа пишется для МСВС и на машине МСВС (там есть собственная среда компиляции, которую по ряду причин не больно просто перенести в среду другого Линукса). Т.е в МСВС есть нормальная среда пакетной разработки - и через automake и и через QMake

А вот ничего, похожего на KDevelop в МСВС нету и по ряду причин собрать его там их исходников невозможно в принципе :(

Но работать хочется по-человечески и возникает мысль, что машинки можно соединить сетью, работать на разработчицкой, а исполнимый модуль пущать на целевой. Для этого на разработчицкой машине нормально поднимается KDevelop, на целевой - NSF-сервер и SSH-сервер. В результате имеем, что файлы проекта физически лежат в МСВС, но KDEvelop их прекрасно видит, включает в проект, и даже сам проект по NFS сохраняет на целевой машине. Открываем терминал SSH и получаем возможность запускать компиляцию в среде МСВС с машины разработчика... Руками. А вот как сделать так, чтобы KDevelop запускал компилятор не по умолчанию (в среде той ОС, в которой он выполняется), а тот, который программист запускает руками в окне SSH?

Как мне представляется, это очень несложное действие - нужно просто где-то сказать KDevelop, что ссылка на shell у него теперь вот такая - и всё. Вот только где это сказать?

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

Есть близкая по смыслу тема http://www.linux.org.ru/view-message.jsp?msgid=660162, но она не годится тем, что в ней KDevelop запускается именно на целевой машине, но использует Иксы, находящиеся на другой. Здесь ситуация другая - на целевой машине нет KDEvelop.

Ответ на: комментарий от gaa

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

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

Так вот, МСВС - это изделие, сделанное в данном технологическом подходе. И, похоже, сделанное под воздействием тех же причин, что действовали и в СССР... :( Головы уже двадцать лет, как нет, а руки-то - помнят!

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

А что делать? Попробуем, в общем... Работать-то и так можно, просто стр-р-р-ашно неудобно и утомительно.

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

Потому, что он не собирается. Начисто - в libc в связи с обеспечением МСВС функций секретности внесены некоторые изменения, в результате которых она перестала быть libc совместимой с системой Linux. Как следствие, с той libc, что есть в МСВС KDevelop не скомпилить (разве что в самой доисторической версии, так такую и сам ВНИИНС компилил, просто в ней работать невозможно), а ту libc, что требует KDevelop в МСВС не поставить. Это признаёт и сам ВНИИНС - там открыто говорят, что если б они могли скомпилить KDEvelop в МСВС, то они бы и сами скомпилили... :)

jivopyra
() автор топика
Ответ на: комментарий от jivopyra

> Потому, что он не собирается. Начисто - в libc в связи с обеспечением МСВС функций секретности внесены некоторые изменения, в результате которых она перестала быть libc совместимой с системой Linux.

Слинкуй статически, может поможет. И, кстати, странно, я там свежий mysql собрал без проблем.

И всё же посмотри на vim+clewn. Оно удобно и наверняка там соберётся.

gaa ★★
()
Ответ на: комментарий от gaa

== Слинкуй статически, может поможет. И, кстати, странно, я там свежий mysql собрал без проблем. ==

Там проблема не в самом KDevelop, там надо поднимать KDE, поскольку по умолчанию там ELK... там зависимостей много, а МСВС - древняя. В общем, уже пытались :) В каком-нибудь пакете, да выплывет, что ему нужна не такая, как есть libc - и всё. Я думаю, что это свойство KDE, но кому ж охота так глубоко копать?

А MySQL (и Qt) тем всю дорогу и отличались, что собирались хорошо :) Хорошо, когда у проекта есть системно мыслящий архитектор...

== И всё же посмотри на vim+clewn. Оно удобно и наверняка там соберётся. ==

Это не вопрос, когда проблема только "посмотреть". Вопрос в том, как в него переехать, если он подойдёт? Наверное, не в самой середине разработки действующего проекта, ну, и т.д. Так что остроты текущего вопроса это не уменьшает, к сожалению.

jivopyra
() автор топика
Ответ на: комментарий от jivopyra

> Там проблема не в самом KDevelop, там надо поднимать KDE, поскольку по умолчанию там ELK... там зависимостей много, а МСВС - древняя. В общем, уже пытались :)

Ну раз вы такие крутые, что уже пытались там кеды пересобрать, то почему б не пропатчить на своей девелоперской тачке kdevelop, чтобы он запускал вместо sh ssh? Делов-то там на 5 минут с sed и grep.

gaa ★★
()
Ответ на: комментарий от gaa

== то почему б не пропатчить на своей девелоперской тачке kdevelop, чтобы он запускал вместо sh ssh? ==

Это мысль...

jivopyra
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.