Использование LCL в fpc

[darkpenguin]

Если я правильно понял, то такая схема будет работать. Верно?

Да, в этом и смысл. Можно распространять исходники и компилировать их хоть на винде, хоть на линуксовом сервере без графического интерфейса, хоть на Raspberry Pi, и при этом не нужно насиловать всё это установкой гигантского графического приложения, которое вообще в сборке никак не задействовано, кроме как запустить компилятор по нажатию кнопки.

[Лекс Айрин]

У меня меню прописывается в исходном коде самой программы.

А у меня не прописывается. Лично у меня просто в классе перечислены пункты меню и методы ими вызываемыми, но связь друг с другом описывается в файле ресурсов.

Нет, они "поставляются" в виде исходников, из которых серверы автоматической сборки уже компилируют всё так чтобы пользователям было удобно ставить.

Когда говорят о поставке в исходных кодах, то речь идет о сборке на стороне пользователя(у конечного пользователя) и никак иначе. Доступ пользователя к исходным текстам программы тут ни при чем.

причём, один от другого даже не зависит (!!). Они рекомендуют друг друга, но не зависят друг от друга, и уж точно они - не "единое целое".

ок. Предоставьте нам ссылку на лазарус БЕЗ LCL, но с другой библиотекой компонент. Причем, он должен с ней перекомпилироваться (это важно!). Ну или хотя бы ссылку на то как этого можно добиться. Тайфун не предлагать! Очень хочу попробовать поюзать.

А в чём же ещё писать консольные программы?)) В текстовом редакторе?))

Угу... есть несколько редакторов, причем, достаточно удобных, чтобы делать это. Например, Geany, Notepad++... в конце-концов, даже встроенная в FPC консольная версия IDE.

Однако, поскольку большинство участвующих в обсуждении даже и не в курсе, что собирать такую программу можно без Лазаруса - при сборке пакета для распространения они, недолго думая, укажут в зависимостях Лазарус.

Ну почему... просто это "Неуловимый Джо" (тот самый, который никому не нужен). Если использовать LCL, то нет смысла пропускать все плюшки среды, Zub, уже пару раз ткнул меня носом в этот факт. Один раз с отладчиком, а второй с PO файлами. А если использовать win/lin API напрямую, то не нужен LCL.

потому что Delphi <s>травмировал мой мозг еще в школе</s> приучил к визуальному программировании и я больше не могу работать в других средах отличных от Delphi/Lazarus

У меня другая беда... я "травмирован" стандартной версией паскаля. Пока я понял КАК надо программировать, я отстал от текущих тенденций (Лучше даже сказать практик). Плюс, не было доступа к справке и не хотелось пользоваться контрафактом. И ставя что-то иное я просто не мог понять идеологии. Lazarus позволил снизить порог вхождения. Возможно, я теперь смогу написать напрямую в текстовом редакторе, но использовать что-то менее дружелюбное визуальное ломает. Т. е. либо визуальное программирование, либо чисто текст.

Да, так обычно и делается - в текстовом редакторе с подсветкой кода, а IDE - либо чтобы потом отлаживать всё это, либо чтобы формы быстрее делать.

Есть практики с быстрым циклом написания/отладки (экстремальное программирование). В этом случае, отладка идет практически сразу после написания фишек. И использование чего-то внешнего нерационально.

И поэтому меня и интересовало, можно ли Лазарусом прикрутить форму к программе, не потеряв возможность продолжать работать и собирать программу без него.

То есть, хочется и рыбку съесть и шкурку сдать? Есть один способ более сложный, но зато позволяющий уменьшить размер программы -- можно скопировать определенные файлы (компоненты) к себе в проект и повыкидовать оттуда лишние зависимости. Но это джин в бутылке.(Есть шанс получить не компилирующийся проект)

Добавлено спустя 4 минуты 44 секунды:

Да, в этом и смысл. Можно распространять исходники и компилировать их хоть на винде, хоть на линуксовом сервере без графического интерфейса, хоть на Raspberry Pi, и при этом не нужно насиловать всё это установкой гигантского графического приложения,

Погуглите что-такое кросс-компиляция... я один раз так попал и случайно скомпилил виндовую прогу под линуксом))) И в случае когда нет возможности скомпилить на целевой платформе проще использовать именно кросс-компиляцию. К тому же, если нет возможности запустить лазарус, то не факт, что и программа запустится после компиляции.

[vitaly_l]

Да, в этом и смысл. Можно распространять исходники и компилировать их хоть на винде, хоть на линуксовом сервере без графического интерфейса

Сам графический интерфейс для компиляции: 100% - ненужен. Всё можно легко компилировать из командной строки. Очевидно, что всё "лишнее" в такой ситуации можно удалить из директории Лазаруса. И это: 100% - будет работать на винде (и запуск будет из командной строки).

Но вот можно ли так сделать на Линуксе?

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

.

[Снег Север]

У меня на виртуалбоксе дома стоит не только линукс-минт, но и макос и винХР. На виртуальном линуксе лазарь летает. А уж поставить лазарь на сервер - вообще не могу понять, в чем может быть проблема.

[darkpenguin]

В том-то и дело, что для сборки "графический интерфейс" не нужен, но, видимо, нынче программисты знают только один способ скомпилировать программу: открыть графический интерфейс и нажать "Компилировать". И оправдывают это ложными утверждениями, что "А по-другому и нельзя, это как собирать самолёт на велосипедном заводе! Лазарус и LCL - это неразделимое целое!".

Но, действительно, во многих случаях хочется уметь скомпилировать проект без "графического интерфейса" (на самом деле, Lazarus - это не только интерфейс, поэтому неправильно так называть; это называется IDE - "интегрированная среда разработки"). И в случае с Лазарусом не очень очевидно, как это сделать, потому что вместе с ним предоставляется также библиотека LCL, в которой и лежат все те "графические" компоненты, которые Lazarus помогает использовать. И многим просто в голову не приходит, что на самом деле это разные вещи, просто распространяются обычно вместе.

На самом деле, они вполне работают по отдельности. Запускать Lazarus без LCL - можно, но обычно не имеет смысла; но вот использовать LCL без Lazarus - вполне имеет смысл, если нужно "просто скомпилировать проект". Как это сделать - я и описал в той статье, для тех, кто даже после этого не верит, что это возможно.

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

Не совсем так.

Запустить виндовую версию Лазаруса или FPC на линуксе нельзя (по крайней мере, без Вайна). Надо установить на сервер линуксовую версию FPC - либо с сайта, либо из репозиториев. (Есть и более извращённые способы это сделать, но это уже оффтопик.)

После этого, можно продолжать разрабатывать свой проект на своём компьютере, а потом закачивать директорию с проектом на сервер и запускать на сервере компиляцию прямо из командной строки. Это и есть "обычный", первоначальный способ, как это делается.

Пока я понял КАК надо программировать, я отстал от текущих тенденций (Лучше даже сказать практик).

У меня было наоборот. Я начинал изучать Pascal, а потом увидел такие замечательные инструменты как Delphi; я могу пользоваться ими, но благодаря этому я действительно понимаю, что они делают "на самом деле". Так же как я начинал изучать никсовые системы "снизу", с командной строки и "как всё работает на самом деле", и теперь я могу пользоваться удобными графическими инструментами (например, Synaptic), но при этом я знаю, что именно они делают и как при необходимости сделать то же самое без них (apt-get). И я продолжаю изучать всё именно с таким подходом - "меч тебе не положен, пока не научишься драться палкой". Поэтому, пользуясь Lazarus, я хочу точно знать, как именно он компилирует мой проект, а не просто "нажимаешь кнопку - и готово". Поэтому теперь я и понимаю, как это на самом деле происходит, и не поддаюсь заблуждениям вроде "так нельзя, вдруг там какие-нибудь ресурсы не упакуются".

"Связь друг с другом - в файле ресурсов"?.. Какая между ними ещё должна быть "связь", кроме описания класса?..
http://wiki.lazarus.freepascal.org/Lazarus_Resources
В ресурсном файле хранятся ресурсы, которые можно запихиваются туда архиватором, входящим в состав Лазаруса, в момент добавления их в проект. После этого ресурсный файл распространяется вместе с исходниками и с помощью линковщика FPC линкуется в бинарник. Но если вдруг надо, то в FPC тоже есть свой архиватор для этого.

Предоставьте нам ссылку на лазарус БЕЗ LCL, но с другой библиотекой компонент.

Я ничего не говорил про "другую библиотеку компонент". Я сказал, что в репозитории как минимум Debian пакет lcl не зависит от пакета lazarus. "Зависит" - это технический термин, и он означает, что у пакета lcl в графе "Depends:" не прописан пакет lazarus. Он прописан в графе "Recommends:", и для этого есть другой термин - "Рекомендует". Тем не менее, я проверил и убедился, что и то, и другое работает по отдельности. (Хотя я не проверял, что именно в Lazarus работает, а что нет, поскольку действительно мало смысла использовать Lazarus без LCL.)

Когда говорят о поставке в исходных кодах, то речь идет о сборке на стороне пользователя(у конечного пользователя) и никак иначе. Доступ пользователя к исходным текстам программы тут ни при чем.

Я говорил о "доступности" исходных кодов, то есть, предложение "распространять бинарник и зажать исходники" - не годится, ибо таким образом я как минимум по-хамски отношусь к своим пользователям, отнимая у них возможность скомпилировать программу так как они хотят (а как максимум - лишаю себя возможности лицензировать программу по GPL, потому что он такого отношения к пользователям не позволяет).

Угу... есть несколько редакторов, причем, достаточно удобных, чтобы делать это. Например, Geany, Notepad++... в конце-концов, даже встроенная в FPC консольная версия IDE.

Ну почему... просто это "Неуловимый Джо" (тот самый, который никому не нужен). Если использовать LCL, то нет смысла пропускать все плюшки среды, Zub, уже пару раз ткнул меня носом в этот факт. Один раз с отладчиком, а второй с PO файлами. А если использовать win/lin API напрямую, то не нужен LCL.

Так "нет смысла пропускать все плюшки среды" и если не пользуешься LCL, а просто пишешь консольную утилитку. И да, в первую очередь это удобство отладки и возможность собирать по нажатию одной кнопки.

Добавлено спустя 9 минут:

У меня на виртуалбоксе дома стоит не только линукс-минт, но и макос и винХР. На виртуальном линуксе лазарь летает. А уж поставить лазарь на сервер - вообще не могу понять, в чем может быть проблема.

Проблема в том что он там не нужен! Он занимает место, тянет за собой зависимости... Для некоторых всё это может быть незначительно, но для тех, кто следит за "чистотой" системы и не будет делать ничего лишнего без хорошей причины - особенно на сервере! - это имеет значение. Особенно если мы говорим о сервере, на котором обычно даже Иксы не установлены, а не о домашнем компьютере. Представьте, что будет, если "настоящий" сисадмин в серьёзной фирме захочет установить вашу CGI-программу в несколько килобайт размером, а она тянет за собой полтора гигабайта зависимостей, включая Иксы и всевозможные графические библиотеки? Он может и на своём компьютере её скомпилировать, но тогда каждую новую версию ему придётся (возможно, кросс-)компилировать самому; лучше просто установить её из вашего репозитория, где она обновляется автоматически, и тогда она будет обновляться вместе со всей остальной системой. Но чтобы это было возможно - сначала надо научиться следовать "правилам хорошего тона" свободного сообщества, и "никаких лишних зависимостей" - это настолько естественно, что вряд ли даже где-нибудь упомянуто.

Добавлено спустя 6 минут 45 секунд:
А ещё, кстати, на какой-нибудь американской ферме, где до сих пор диалап, или где-нибудь в Сьерра-Лионе, где у кого-то может быть только Raspberry Pi с двухгигабайтной флешкой и вообще не знаю как с интернетом, а возможно, и в какой-нибудь русской глубинке - вопрос скачивания нескольких сотен метров лишних зависимостей становится достаточно значительным даже для обычных пользователей.

[Лекс Айрин]

А уж поставить лазарь на сервер - вообще не могу понять, в чем может быть проблема.

Видимо, дело в том, что для сервера не обязательно иметь графическую оболочку. Не помню, правда, есть ли она у лазаруса в зависимостях, но, насколько мне известно, для установки это не играет роли (если что, то библиотеки подтянутся.)

[darkpenguin]

Дело не в том, почему *я* не хочу ставить это на сервер - дело в том что *кто-то другой* может по каким-нибудь, любым, причинам не захотеть этого делать. И у нас (как минимум линуксоидов) принято задумываться о таких вещах, когда мы упаковываем свой софт и думаем, какие прописать зависимости и как написать Makefile .

[Лекс Айрин]

Запускать Lazarus без LCL - можно, но обычно не имеет смысла

Стоп! Докажите? Фишка лазаруса в том, что он способен перекопилировать сам себя. А без LCL это как бы очень затруднительно.

библиотека LCL

угу... а ВЫ лично интересовались как расшифровывается эта аббревиатура? Lazarus Component Library

Так "нет смысла пропускать все плюшки среды" и если не пользуешься LCL, а просто пишешь консольную утилитку.

А как их можно использовать, если это плюшки заточены под LCL? Редакторы: меню, привязок,... Менеджер компонент... они просто не работают в консольном режиме.

А ещё, кстати, на какой-нибудь американской ферме, где до сих пор диалап, или где-нибудь в Сьерра-Лионе, где у кого-то может быть только Raspberry Pi с двухгигабайтной флешкой и вообще не знаю как с интернетом, а возможно, и в какой-нибудь русской глубинке - вопрос скачивания нескольких сотен метров лишних зависимостей становится достаточно значительным даже для обычных пользователей.

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

Представьте, что будет, если "настоящий" сисадмин в серьёзной фирме захочет установить вашу CGI-программу в несколько килобайт размером, а она тянет за собой полтора гигабайта зависимостей, включая Иксы и всевозможные графические библиотеки?

Может я, конечно, что-то не понимаю, но зачем CGI программе вообще графический интерфейс? Если я правильно помню, то это лишь сервис (демон) который используется сервером чисто в консольном режиме и выхлоп используется чисто для внутренних дел сайта (подготовки данных для страницы и/или ее сборки). А если он есть, то сама программа потянет за собой его независимо от наличия/отсутствия компилятора или среды разработки.

Представьте, что будет, если "настоящий" сисадмин в серьёзной фирме захочет установить вашу CGI-программу в несколько килобайт размером, а она тянет за собой полтора гигабайта зависимостей, включая Иксы и всевозможные графические библиотеки?

Кстати, на серверы все же может ставиться графическая среда -- для удобства настройки/обслуживания. Дело в том, что нормальный админ не будет все настраивать с нуля, если есть возможность схалтурить без ущерба для работы. И, если уж на то пошло, под С/С++ это вполне нормальное явление -- взять хотя бы .NET framework или те же Gnome/KDE.

Добавлено спустя 4 минуты 5 секунд:
darkpenguin, если человек хочет странного (например, поставить программу с графическим интерфейсом на сервер без графического ядра), то никакие думы программиста ему не помешают.

[darkpenguin]

Стоп! Докажите? Фишка лазаруса в том, что он способен перекопилировать сам себя. А без LCL это как бы очень затруднительно.

Чтобы "использовать фишки Лазаруса", надо установить опциональные пакеты для использования тех возможностей, которые нужны. Этим Recommends: отличается от Depends: .

А как их можно использовать, если это плюшки заточены под LCL? Редакторы: меню, привязок,... Менеджер компонент... они просто не работают в консольном режиме.

"Не использовать LCL" означает, к примеру, создать проект типа "Консольное приложение" и не использовать в нём модули LCL. Тогда они не будут необходимы, чтобы собрать это приложение. При этом можно пользоваться удобным графическим текстовым редактором в Lazarus, дебаггером, удобной компиляцией "одной кнопкой" и прочим. То что Lazarus использует LCL, в том числе для отображения своего графического интерфейса - не значит, что ваш проект обязательно будет зависеть от LCL при сборке!

Если я правильно помню, то это лишь сервис (демон) который используется сервером чисто в консольном режиме и выхлоп используется чисто для внутренних дел сайта

Именно. Поэтому ей НЕ НУЖЕН графический интерфейс. И поэтому при её сборке не обязательно устанавливать графическую среду разработки Lazarus и библиотеку графических компонент LCL.

И, если уж на то пошло, под С/С++ это вполне нормальное явление -- взять хотя бы .NET framework или те же Gnome/KDE.

Вы действительно не поняли, в чём проблема. Под C/C++ можно собрать пакет, который для сборки и установки будет требовать только make, компилятор и те библиотеки, которые он действительно использует (.NET, gtk или Qt). Так и работают все пакеты в линуксе. Они не требуют установить Microsoft Visual Studio для того чтобы собрать и поставить пакет. И это - стандарт, которого надо придерживаться. И вот я и задался вопросом - а возможно ли придерживаться этого стандарта при разработке программ на Lazarus? Позволит ли он устанавливать пакеты с помощью только make, компилятора Free Pascal Compiler и только тех библиотек, которые этот пакет действительно использует? Оказалось, что он это позволяет. Однако, многие программисты, использующие Lazarus, вообще не задумываются ни о пользователях, ни о стандартах, ни о других платформах или операционных системах... поэтому им и в голову не приходит, что кому-то может понадобиться поддерживать общепринятые стандарты при использовании Lazarus IDE.

[Лекс Айрин]

Чтобы "использовать фишки Лазаруса", надо установить опциональные пакеты для использования тех возможностей, которые нужны.

Не прокатит. Установка пакетов в лазарусе происходит только перекомпиляцией всей среды (не инсталляция, а именно установка для использования). Если убрать LCL, то лазарус просто не соберется.

И поэтому при её сборке не обязательно устанавливать графическую среду разработки Lazarus и библиотеку графических компонент LCL.

И о чем тогда речь? Если не нужна LCL, то не нужен для сборки и лазарус. Более того, Есть возможность собрать под ним и графическое приложение не использующее LCL, которое легко и непринужденно соберется в FPC. Возможно, что придется переименовать расширение у файла проекта.

Позволит ли он устанавливать пакеты с помощью только make, компилятора Free Pascal Compiler и только тех библиотек, которые этот пакет действительно использует? Оказалось, что он это позволяет.

Я бы не назвал это так уж и позволяет. Надо проверять на машине без следов лазаруса, где есть только LCL и lazbuild. Кстати, сам lazbuild, судя по всему, есть не более чем упрощенная версия Lazarus использующая все тот же LCL, но в режиме NoGUI. Кстати, подобное существовало еще в турбопаскале.

которые он действительно использует (.NET, gtk или Qt).

Так и лазарус есть точно такая же библиотека. И для установки микроскопической утилитки приходится ставить всю .NET ..в том числе и с утилитами и даже компиляторами. (у меня точно есть консольники явы и бейсика)

[darkpenguin]

Установка пакетов в лазарусе происходит только перекомпиляцией всей среды

"Пакеты" - я имел в виду не Lazarus "packages", а Debian packages (они тоже называются "пакеты"); т.е. пакет lcl, который указан в Recommends: .

И о чем тогда речь?

Так о том и речь, что это возможно, и о том, как это сделать! Переименовывать не понадобится. И задав такой простой вопрос, я получаю несколько дней обсуждения "зачем вам это нужно", даже после того как сам уже всё описал, в том числе и "зачем". %)

Надо проверять на машине без следов лазаруса, где есть только LCL и lazbuild

Статья именно о том что я всё это проверил и написал, как это делается... И потом повторил здесь, в этой теме. В том числе, что такое lazbuild.

Так и лазарус есть точно такая же библиотека.

Lazarus - это не библиотека, это IDE! Библиотека - это LCL; вот его и надо устанавливать, если программа её использует. Можно отдельно, без Лазаруса.

И для установки микроскопической утилитки приходится ставить всю .NET ..в том числе и с утилитами и даже компиляторами

Да - если программа использует .NET, то надо установить библиотеки .NET Redistributable. Но Microsoft Visual Studio (IDE, в котором эти программы разрабатывались) ставить не надо. И в линуксе надо установить "зависимости" - те, которые действительно нужны. Но строго говоря, тут есть некоторая разница, потому что такие программы скорее всего и распространяются в виде бинарников, и тут мы говорим о runtime зависимостях, а не о build-time зависимостях для сборки чего-то из исходников. И ещё строго говоря, .NET - это вообще отдельная история...

[Снег Север]

Особенно если мы говорим о сервере, на котором обычно даже Иксы не установлены, а не о домашнем компьютере.

Тогда я тем более ничего не понимаю - на кой LCL на сервере на котором нет графической оболочки...

[pupsik]

darkpenguin - опять супер идея? Вовремя бинарные пакеты делайте. А вот игра с сорцами... простому обывателю.

Т.е. ваша идея предполагает лишнюю головную боль. которая необходима в редких случаях.
Тем более предполагается консоль. Зачем тут ЛСЛ? Консоль на то и консоль. Простого редактора (nano или схожее) и фпс с зависимостями выше крыши хватит.

А вот если вы ГУИ без системного АПИ заворотили. И пользователю захотелось что то подправить... чем тогда он формочки шлёпать будет то? Редактором?

Но Microsoft Visual Studio (IDE, в котором эти программы разрабатывались) ставить не надо.

и..и? Опять же. Визуальное приложение. Есть желание подправить формы, добавить своё видение кода..интерфейса и т.д... Чем править?

п.с.
Гиблая какая то идея....

[darkpenguin]

Тогда я тем более ничего не понимаю - на кой LCL на сервере на котором нет графической оболочки...

LCL там может быть и не нужна. Вопрос был в том, "как собрать проект Lazarus с помощью только FPC, без IDE". Зачем - это решать уже конечному пользователю.

pupsik Моя идея - не идея, а желание разрабатывать "настоящий" свободный софт, соответствующий базовым стандартам. И самый первый стандарт - такой софт распространяется в виде исходников с Makefile , и компилируется автоматическими билд-серверами. И без лишних зависимостей.

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

...Я уже не вижу смысла объяснять первое правило свободного софта тем, кто не то что его не знает - но даже и понять не может...

Добавлено спустя 7 минут 12 секунд:
Видимо, Lazarus действительно все воспринимают только как игрушку, "чтобы написать программу для себя", даже и не рассматривая перспективу разрабатывать на нём "серьёзный" софт, который должен соответствовать каким-то требованиям кроме собственных представлений о том, чего достаточно. Бинарника будет достаточно только вам, или кому-то кто кроме бинарников никогда ничего и не видел и даже не понимает, "а зачем".

[vitaly_l]

и даже не понимает, "а зачем"

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