на чем программировать под линукс
Визуальные среды программирования для Linux
NetBeans
QT / KDevelop Designer
Еще одна мощная среда разработки на
платформе KDE и Gnome. Кросс-платформенные C++
приложения выходят только в путь. Для
некоммерческих программ Qt можно
использовать бесплатно, существует
практически для всех дистрибутивов.
Gambas
WYSIWYG редактор для создания web-страниц. Во
многом напоминает редактор Macromedia или все
тот же FrontPage. Поддерживает автоматическую
работу с сайтом по FTP.
Eric
Python и Ruby IDE среда, делающая
программирование на языке довольно простым
и увлекательным. Написанная собственно на
Python.
Eclipse
Более подробно о среде ты можешь
прочитать в нашем Спеце: http://www.xakep.ru//magazine/xs/065/048/1.asp
JDeveloper
Planner
Ну и наконец визуальная среда управления
проектами для Gnome Desktop. Не менее полезная
программа для программистов чем IDE.
Разработка графических приложений под Linux для Windows Программистов. С чего начать? (перевод)
Разработка графических приложений под Linux для Windows Программистов.
С чего начать?
Переходя с Windows на Linux вы начинате путаться в куче опций. QT или GTK+? Какой язык использовать: c/c++/java/perl/tcl/python/ruby или javascript? Должен ли я использовать коммерческие/проприетарные laypout/rad инструмента (QT или Kylix), либо opensource? А Mozilla? Я умею программировать в Visual Basic и Lotus Notes (Basic, Java, C / C + + API). С чего мне начать?
Начинайте с того что нравится
Я знал, что я люблю язык программирования Python, с его способностью сделать программирование «как можно более простым, но не простейшим» (Эйнштейн). Он позволяет программировать на высоком уровне и ваш разум освобождается для работы по другим вопросам. Поскольку структура кода является неотъемлемой частью языка я считаю, что такой код другим людям гораздо легче читать и понимать. Отсутствие необходимости компилировать экономит мне время на отладку и тестирование. Сбор мусора — это то, что я считать само собой разумеющимся. Так же я могу выбрать подходящий для меня стиль программирования, будь то процедурное, функциональное, объектно-ориентированное или смесь — за счет чего я могу выполнить работу более быстро и эффективно. Приложения могут быть заморожены — сделать для облегчения распространения. Наконец, «batteries included» характерное для Python библиотек способствует повторному использованию кода и скорости развития.
Тем не менее, язык программирования, в идеале не должно быть вашим главным критерием в отборе GUI Toolkit — так что я сделал обследование имеющихся инструментов.
Выбор инструментов
Я рассмотрел TK(2), GTK+(3), QT(4), wxWindows(5), MFC, Windows Forms (.NET), Swing (Java), и FOX(6) и пришел к следующим критериям оценки инструментов:
Проприетарная помощь
Три или четыре варианта попираются на вершину. QT и Kylix оба предлагают великолепные, довольно простые в использовании RAD среды. Тем не менее, я использовал FoxPro и Lotus Notes — и я очень устала от собственных решений (оба поддерживают Unix, но я забросил это дело). Закрытость инструмента может очень негативно сказаться на вашем приложении в будущем. Компании создавшие ваше ПО могут принять решение об изменении направления и больше не вкладывать средства в ваш инструмент — и ваше приложение или устаревает, или умирает. Если вы разрабатываете приложение с открытым кодом на QT — вы ограничены в соответствии с лицензией на открытый код. Дорогое лицензии могут быть необходимы для портирования кода на Mac или Windows. Некоторые компании и инструменты (Java & Notes) ограничивают ваше право на распространение кода без дополнительной оплаты лицензий.
Мне нравится нативный вид
GTK+ и TK довольно неуклюже работают под windows и я хотел бы чтобы то что я пишу выглядело замечательно как на windows так и на mac. Посмотрим правде в глаза — большинство пользователей привыкли к использованию родных виджетов и, как правило оценивают приложение, по внешнему виду. Если вы хотите придерживаться стиля Unix то платформа GTK + и PyGTK являются хорошим выбором.
Mozilla — XUL
Другой вариант, кажется интригующим. Им является XUL — XML код, который создает основу для GUI Mozilla.
Среди его преимуществ — кроссплатформенный набор виджетов и возможность установки через браузер (. XPI-файлы) или можно запускать прямо с сервера (на XULPlanet есть прекрасный учебник). Я обнаружил protozilla — который дает способом создания локальных сценариев CGI или с использованием IPC (pipe), — но он показался мне нестабильным. Я также обнаружил, что вы можете получить доступ к COM-объектам через интерфейс IDispatch. Код в настоящее время выключен и не является частью программы Mozilla. Кроме того,код очень сырой, и тщательно не протестирован.
из почтовой рассылки:
Нестабильность Mozilla как платформы для разработки заставила отложить её до лучших времен. Возможно, что все изменится в будущем.
wxWindows
wxWindows это открытый c++ инструмент который работает как тонкая прослойка между родными виджетами — GTK+, WIN32, Mac OS, Motif и т.п. У него имеется интерфейсы для c++, perl, python и ruby. Мне нравится идея набора виджетов, который представляет собой тонкую оболочку вокруг других — тем самым защищая вас от изменений и позволяющий вести кроссплатформенную разработку. Вначале были проблемы запуска WxPython под управлением Linux — Python — WxWindows, но Робин Данни улучшил установку для Linux — и теперь это доступно как обычная установка пакетом.
WxPython была создана Robin, который сделал инструмент, который помогает автоматизировать создание Python классов C или C + + API и WxPython — Python интерфейс для WxWindows. Существуют также интерфейсы для Perl & Ruby для тех, кто предпочитает эти языки. Еще одним преимуществом является возможность использования XML для программирования интерфейса (например, GTK +, QT, XUL). В теории это позволяет отделить графический вид программы от логики отображения. Также я бы хотел отметить, что очень быстро и легко можно создать графический интерфейс приложения. С другой стороны, хотя существует множество фрагментов и примеров кода, имеющихся пособий, большая часть документации, направлена на C + + программистов. Также замечу, что порт на Mac OS X не является полным.
В конце хочется спросить, «Что используют люди поумнее?»
Open Source Applications Foundation приняли решение об использовании WxPython через год раздумий
GNU Entreprise — используют WxPython в качестве основы для приложений клиент-сервер.
Многие другие организации используют WxWindows в той или иной форме
Итак. Какие виджеты я использую?
XRC:
Простой редактор xml widget
Boa:
IDE
Слышал только хорошее и даже немного с ним поигрался
На чем программировать под линукс
Чтобы сразу начать программировать, создадим еще один клон известной программы «Hello World». Что делает эта программа, вы знаете. Откройте свой любимый текстовый редактор и наберите в нем следующий текст:
Наш исходный код написан на языке программирования C. Языки программирования были придуманы для того, чтобы программист мог объяснить компьютеру, что делать. Но вот беда, компьютер не понимает ни одного языка программирования. У компьютера есть свой язык, который называют машинным кодом или исполняемым кодом (‘executable code’). Написать Hello World в машинном коде можно, но серьезные программы на нем не пишутся. Исполняемый код не только сложный по своей сути, но и очень неудобный для человека. Программа, которую можно написать за один день на языке программирования будет писаться целый год в машинном коде. Потом программист сойдет с ума. Чтобы этого не случилось, был придуман компилятор (‘compiler’), который переводит исходный код программы в исполняемый код. Процесс перевода исходного кода программы в исполняемый код называют компиляцией.
Осталось только запустить полученный бинарник. Для этого набираем в командной строке следующую команду:
Когда мы набираем в командной строке путь к бинарнику, мы, в реальности сообщаем оболочке, что надо выполнить программу. Оболочка «передает» бинарник ядру операционной системе, а ядро системы особым шаманским способом отдает программу на выполнение процессору. Затем, если программа не была запущена в фоновом режиме, то оболочка ждет от ядра сообщения о том, что программа выполнилась. Получив такое сообщение, оболочка выдает приглашение на ввод новой команды. Вы можете еще раз набрать ./hello и процедура повторится. В нашем случае программа выполняется очень быстро, и новое приглашение командной строки «вылетает» практически сразу.
Мы рассмотрели идеальный случай, когда программа написана без синтаксических ошибок. Попробуем намеренно испортить программу таким образом, чтобы она не отвечала канонам языка C. Для этого достаточно убрать точку с запятой в конце вызова функции printf(): Теперь, если попытаться откомпилировать программу, то компилятор выругается, указав нам на то, что он считает неправильным: В первой строке говорится, что в файле hello.c (у нас он единственный) в теле функции main() что-то произошло. Вторая строка сообщает, что именно произошло: седьмая строка файла hello.c вызвала ошибку (error). Далее идет расшифровка: синтаксическая ошибка перед закрывающейся фигурной скобкой.
Заглянув в файл hello.c мы с удивлением обнаружим, что нахулиганили мы не в седьмой, а в шестой строке. Дело в том, что компилятор обнаружил нелады только в седьмой строке, но написал ‘before’ (до), что означает «прокручивай назад».
Естественно, пока мы не исправим ошибку, ни о каком бинарнике не может идти и речи. Если мы удалим старый бинарник hello, доставшийся нам от прошлой компиляции, то увидим, что компиляция испорченного файла не даст никакого результата. Однако иногда компилятор может лишь «заподозрить» что-то неладное, потенциально опасное для нормального существования программы. Тогда вместо ‘error’ пишется ‘warning’ (предупреждение), и бинарник все-таки появляется на свет (если в другом месте нет явных ошибок). Не следует игнорировать предупреждения, за исключением тех случаев, когда вы на 100% знаете, что делаете.
2.2. Мультифайловое программирование
Как я уже говорил, если исходный код сколько-нибудь серьезной программы уместить в одном файле, то такой код станет просто нечитаемым. К тому же если программа компилируется достаточно долго (особенно это относится к языку C++), то после исправления одной ошибки, нужно перекомпилировать весь код.
Куда лучше разбросать исходный код по нескольким файлам (осмысленно, по какому-нибудь критерию), и компилировать каждый такой файл отдельно. Как вы вскоре узнаете, это очень даже просто.
Давайте сначала разберемся, как из исходного файла получается бинарник. Подобно тому как гусеница не сразу превращается в бабочку, так и исходный файл не сразу превращается в бинарник. После компиляции создается объектный код. Это исполняемый код с некоторыми «вкраплениями», из-за которых объектный код еще не способен к выполнению. Сразу в голову приходит стиральная машина: вы ее только что купили и она стоит у вас дома в коробке. В таком состоянии она стирать не будет, но вы все равно рады, потому что осталось только вытащить из коробки и подключить.
Итак, чтобы откомпилировать мультифайловую программу, надо сначала добыть объектный код из каждого исходного файла в отдельности. Каждый такой код будет представлять собой объектный модуль. Каждый объектный модуль записывается в отдельный объектный файл. Затем объектные модули надо скомпоновать в один бинарник.
В Linux в качестве линковщика используется программа ld, обладающая приличным арсеналом опций. К счастью gcc самостоятельно вызывает компоновщик с нужными опциями, избавляя нас от «ручной» линковки.
Попробуем теперь, вооружившись запасом знаний, написать мультифайловый Hello World. Создадим первый файл с именем main.c: Теперь создадим еще один файл hello.c со следующим содержимым:
Давайте разберемся, что же все-таки произошло. В этом нам поможет утилита nm. Я уже оговорился, что объектные файлы содержат таблицу символов. Утилита nm как раз позволяет посмотреть эту таблицу в читаемом виде. Те, кто пробовал программировать на ассемблере знают, что в исполняемом файле буквально все (функции, переменные) стоит на своей позиции: стоит только вставить или убрать из программы один байт, как программа тут же превратиться в груду мусора из-за смещенных позиций (адресов). У объектных файлов особая роль: они хранят в таблице символов имена некоторых позиций (глобально объявленных функций, например). В процессе линковки происходит стыковка имен и пересчет позиций, что позволяет нескольким объектным файлам объединиться в один бинарник. Если вызвать nm для файла hello.o, то увидим следующую картину: О смысловой нагрузке нулей и литер U,T мы будем говорить при изучении библиотек. Сейчас же важным является то, что в объектном файле сохранилась информация об использованных именах. Своя информация есть и в файле main.o: Таблицы символов объектных файлов содержат общее имя print_hello. В процессе линковки высчитываются и подставляются в нужные места адреса, соответствующие именам из таблицы. Вот и весь секрет.
2.3. Автоматическая сборка
В предыдущем разделе для создания бинарника из двух исходных файлов нам пришлось набрать три команды. Если бы программу пришлось отлаживать, то каждый раз надо было бы вводить одни и те же три команды. Казалось бы выход есть: написать сценарий оболочки. Но давайте подумаем, какие в этом случае могут быть недостатки. Во-первых, каждый раз сценарий будет компилировать все файлы проекта, даже если мы исправили только один из них. В нашем случае это не страшно. Но если речь идет о десятках файлов! Во-вторых, сценарий «намертво» привязан к конкретной оболочке. Программа тут же становится менее переносимой. И, наконец, простому скрипту не хватает функциональности (задание аргументов сборки и т. п.), а хороший скрипт (с многофункциональными прибамбасами) плохо модернизируется.
То, что выполняет утилита make, называется сборкой проекта, а сама утилита make относится к разряду сборщиков.
Любой Makefile состоит из трех элементов: комментарии, макроопределения и целевые связки (или просто связки). В свою очередь связки состоят тоже из трех элементов: цель, зависимости и правила.
Сценарии make используют однострочные комментарии, начинающиеся с литеры # (решетка). О том, что такое комментарии и зачем они нужны, объяснять не буду.
Макроопределения позволяют назначить имя практически любой строке, а затем подставлять это имя в любое место сценария, где должна использоваться данная строка. Макросы Makefile схожи с макроконстантами языка C.
Теперь рассмотрим пример. Попробуем составить сценарий сборки для рассмотренного в предыдущем разделе мультифайлового проекта Hello World. Создайте файл с именем Makefile: Обратите внимание, что в каждой строке перед вызовом gcc, а также в строке перед вызовом rm стоят табуляции. Как вы уже догадались, эти строки являются правилами. Формат Makefile требует, чтобы каждое правило начиналось с табуляции. Теперь рассмотрим все по порядку.
Makefile может начинаться как с заглавной так и со строчной буквы. Но рекомендуется все-таки начинать с заглавной, чтобы он не перемешивался с другими файлами проекта, а стоял «в списке первых».
Первая связка имеет цель hello. Цель отделяется от списка зависимостей двоеточием. Список зависимостей отделяется от правил символом новой строки. А каждое правило начинается на новой строке с символа табуляции. В нашем случае каждая связка содержит по одному правилу. В списке зависимостей перечисляются через пробел вещи, необходимые для выполнения правила. В первом случае, чтобы скомпоновать бинарник, нужно иметь два объектных файла, поэтому они оказываются в списке зависимостей. Изначально объектные файлы отсутствуют, поэтому требуется создать целевые связки для их получения. Итак, чтобы получить main.o, нужно откомпилировать main.c. Таким образом файл main.c появляется в списке зависимостей (он там единственный). Аналогичная ситуация с hello.o. Файлы main.c и hello.c изначально существуют (мы их сами создали), поэтому никаких связок для их создания не требуется.
Особую роль играет целевая связка clean с пустым списком зависимостей. Эта связка очищает проект от всех автоматически созданных файлов. В нашем случае удаляются файлы main.o, hello.o и hello. Очистка проекта бывает нужна в нескольких случаях: 1) для очистки готового проекта от всего лишнего; 2) для пересборки проекта (когда в проект добавляются новые файлы или когда изменяется сам Makefile; 3) в любых других случаях, когда требуется полная пересборка (напрмиер, для измерения времени полной сборки).
Теперь осталось запустить сценарий. Формат запуска утилиты make следующий: Опции make нам пока не нужны. Если вызвать make без указания целей, то будет выполнена первая попавшаяся связка (со всеми зависимостями) и сборка завершится. Нам это и требуется: В процессе сборки утилита make пишет все выполняемые правила. Проект собран, все работает.
Теперь давайте немного модернизируем наш проект. Добавим одну строку в файл hello.c: Теперь повторим сборку: Утилита make «пронюхала», что был изменен только hello.c, то есть компилировать нужно только его. Файл main.o остался без изменений. Теперь давайте очистим проект, оставив одни исходники: В данном случае мы указали цель непосредственно в командной строке. Так как целевая связка clean содержит пустой список зависимостей, то выполняется только одно правило. Не забывайте «чистить» проект каждый раз, когда изменяется список исходных файлов или когда изменяется сам Makefile.
2.4. Модель КИС
Итак, сервер предоставляет услуги. В нашем случае это могут быть функции, структуры, перечисления, константы, глобальные переменные и проч. В языке C++ это чаще всего классы или иерархии классов. Любой желающий (клиент) может воспользоваться предоставленными услугами, то есть вызвать функцию со своими фактическими параметрами, создать экземпляр структуры, воспользоваться константой и т. п. В C++, как правило, клиент использует класс как тип данных и использует его члены.
Надоело быть простым Linux дэсктоп-юзверем 🙂
Цитата с озона: Книга предназначена для программистов, уже знакомых с языком С и имеющих базовый опыт.
У меня нет базового опыта 🙂 У меня вообще никакого опыта нету.
Тут на форуме был замечен тред (и не один) на эту тему. Воспользуйся поиском. Лично я Си изучал по разным источникам, в основном опираясь на опыт в Паскале и чужие исходники. В настоящее время в качестве справочного пособия (по C++, ибо с Сями проблем не возникает) пользуюсь трактатом Страустрапа.
Ищи в электронном виде документ: «Хрестоматия по программированию на Си в Unix» А. Богатырев. Например тут: http://www.opennet.ru/docs/RUS/bogatyrev/
Почитай Страустропа, только ищи специально издание, там ISO C++. Если с английским нормальное, то могу прислать эту книгу в PDF. Но она есть в магазинах и на русском.
Велик могучим, ё-моё 🙂
нда, прошу прощения
рекомендованная книга http://www.ozon.ru/context/detail/id/986013/ совершенно однобокая, всякие межпроцессорные коммуникации. Гораздо интереснее и полезнее, как пишутся правильные GNU/linux программы: работа с локалью, всякие automake, autoconf.
Благодарю всех за советы, ссылки. Спасибо.
Дело в том, что мне ничего конкретного делать не нужно 🙂
Мне вообще ничего делать не нужно. (Это я про создание программ)
Я хочу выучить какой-либо язык программирования и научится создавать примитивные приложения.
Учебник английского. Я серьёзно. Хотя кое-какие базовые книжки уже перевели. Кнута, например, можно почитать по-русски параллельно с учебником английского 🙂
> В программировании я полный ноль.
При умении читать по-английски это вполне поправимо. Главное, не считать, что знание языков программирования делает тебя программистом.
ну на самом деле правильно посоветовали
Случайные заметки
Блог продолжающего linux-оида.
пятница, октября 28, 2011
Введение в прикладное программирование под GNU/Linux
Это конспект, который я готовил для доклада на конференции, проводившейся местным университетом совместно с нашей LUG. Доклад «для самых маленьких», так что профессионалам просьба не жаловаться на поверхностность и обзорность.
Аудитория
Эта статья расчитана на два вида читателей. Во-первых, это люди, имеющие опыт программирования под MS Windows, но не имеющие такого опыта под GNU/Linux. Во-вторых, это люди, не имеющие опыта программирования вовсе. Однако, я предполагаю, что читатель в общем знаком с общепринятой в программировании терминологией, и ему не нужно объяснять, например, что такое «программа», «функция», «компилятор» или «отладка».
Средства разработки
Я буду рассматривать разработку с использованием тех средств, которые являются наиболее «родными» для GNU/Linux. К ним относятся:
Язык программирования C
Командная оболочка bash
Текстовые редакторы Vim и Emacs
Утилита для сборки проекта GNU make
Система управления версиями Git
Оконная система X11
Выбор именно этих средств не является догмой. Каждое из выше перечисленных средств может быть при желании заменено на другое. Однако, обычно под фразами наподобие «среда разработки Linux» понимается именно этот набор инструментов.
Языки программирования
Наиболее «родным» языком программирования для GNU/Linux является C. Это обусловлено следующими факторами:
GNU/Linux заимствует многие идеи (практически, идеологию) операционной системы UNIX;
Операционная система UNIX была написана на языке C (собственно, этот язык создавался именно для написания этой ОС);
Соответственно, ядро Linux и системное окружение GNU написаны тоже на C.
Ниже я буду рассматривать разработку с использованием языка C. Однако, этот выбор не является догмой. Другими популярными при разработке под GNU/Linux языками являются C++, Python, Perl. Конечно, могут использоваться и любые другие языки.
Среда разработки
В течение последних двух десятилетий очень широкое распространение получили т.н. IDE — интегрированные среды разработки. Такая среда включает в себя текстовый редактор, компилятор, отладчик, средства сборки проекта и мн.др. Такие среды есть и под GNU/Linux (наиболее популярны Eclipse, NetBeans, IDEA, KDevelop, Anjuta). Однако, история разработки под UNIX-подобные системы показывает, что IDE не являются не только единственным, но и наиболее эффективным средством разработки. Практически, правильный ответ на вопрос «какая самая лучшая IDE под GNU/Linux» — это «GNU/Linux это и есть IDE».
Часто можно встретить мнение, что большой проект без IDE разрабатывать невозможно. Это мнение легко опровергается. Первые версии UNIX писались даже не в Vim (его тогда ещё не было), а в Ed. Это так называемый «построчный» текстовый редактор, в котором вы можете редактировать за раз только одну строку текста. Весь файл на экране не отображается. В случае с UNIX по-другому и быть не могло — у разработчиков не было никаких экранов, а общение с системой осуществлялось при помощи телетайпов. Современное ядро Linux пишется в основном в редакторах Emacs и Vim.
Многие утилиты UNIX вызывают «текстовый редактор по умолчанию». Команда, запускающая текстовый редактор по умолчанию, берётся из переменной окружения $EDITOR. Некоторые утилиты смотрят сначала в переменную $VISUAL, и, лишь если она не установлена, в переменную $EDITOR. Это исторически сложившееся поведение: к старым компьютерам зачастую не было подключено никакого дисплея, а только телетайп, поэтому запускать экранный (визуальный) редактор смысла не было. В современных дистрибутивах обычно по умолчанию оказывается EDITOR=vi или EDITOR=nano. Указать использование другого редактора для одной команды можно так:
Чтобы использовать нужный редактор по умолчанию всегда, нужно добавить в файл
/.profile строчку типа
Исторически сложилось так, что «настоящими» текстовыми редакторами для программистов являются только Vim и Emacs (просто из-за того, что у них самая долгая история развития именно в качестве текстовых редакторов для программистов). Остальные редакторы находятся в положении догоняющих.
Командная оболочка
Командная оболочка (или командный интерпретатор) — это программа, принимающая команды от пользователя на некотором достаточно простом языке программирования и выполняющая их. Большинство команд запускают одноимённые программы. Отдельные команды представляют собой конструкции языка программирования оболочки.
Стандарт POSIX включает описание минимального набора возможностей, предоставляемых командной оболочкой. Реально используемые оболочки предоставляют, как правило, больше возможностей.
ОС семейств DOS и Windows заимствовали некоторые функции командной оболочки из UNIX, однако их авторы пошли на существенные упрощения, из-за чего функционал COMMAND.COM и cmd.exe получился сильно урезанным. PowerShell вполне на уровне, но работает существенно по-другому.
В рамках этой статьи я ограничусь использованием командной оболочки bash (как наиболее распространённой и используемой по умолчанию в большинстве дистрибутивов) для запуска компилятора и других средств разработки. Хороший обзор использования командной оболочки можно найти, например, в известной книге [kernigan_pike].
Документация
Все средства разработки и библиотеки в GNU/Linux обычно довольно хорошо документированы. Традиционно для документации используется специальный формат и утилита для его просмотра — man. Документация в системе делится на несколько разделов:
Команды пользователя (например, ls, gcc или man)