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

Вопросы программирования на Free Pascal, использования компилятора и утилит.

Модератор: Модераторы

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

Сообщение Лекс Айрин » 16.06.2017 18:06:18

daesher писал(а):Но требуется тащить всюду весь Lazarus.


А его и так придется тащить почти весь. Потому что Lazarus это и есть преимущественно LCL. Сам код лазаря, по сравнению с компонентами небольшой.

daesher писал(а):Я могу предположить, что путём жесточайших издевательств над кодом можно объединить два одноимённых модуля, но штатными средствами это не получится: компилятор будет искать модуль с определённым именем в пути поиска, и как только найдёт - будет использовать именно его.

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

daesher писал(а):компилятор будет искать модуль с определённым именем в пути поиска, и как только найдёт - будет использовать именно его.


а тут есть пара пассов руками в компиляторе и Лазаре. Для различных библиотечных пакетов различается порядок путей, а следовательно имена одноименных модулей будут различны. Тоже касается и мультиплатформенной поддержки (А вот модули System, для различных платформ различаются ).
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 17.06.2017 00:35:44

Лекс Айрин писал(а):А его и так придется тащить почти весь. Потому что Lazarus это и есть преимущественно LCL. Сам код лазаря, по сравнению с компонентами небольшой.

Ну почему? Давайте посмотрим svn, там ничего откомпилированного нет. LCL 34,5 Мб, из них interfaces 26,8 (из которых мы берём только один, допустим, gtk2 1,9 Мб) - итого из lcl будет 9,6 Мб. Остаются совсем кусочки из components - это 3,9 Мб. Итого 13,5 Мб для сборки. Всего components занимают 67,9 Мб, но, допустим, кому-то там что-то надо.
Тогда давайте считать только ненужное для сборки проекта (напомню, нужного у нас 13,5 Мб, всё остальное - по необходимости, которой в 90 % случаев нет). Итак, лишние интерфейсы - 24,9 Мб; codetools (для сборки абсолютно не нужны) - 6,1 Мб, ide - 9 Мб, и ещё всякой мелочёвки наберётся. Короче, гарантированно ненужного хлама получилось раза в 3 больше, чем того, что надо. И это - только в исходниках, в откомпилированном виде эту цифру, как минимум, утройте (модули + исполняемые файлы).
Лекс Айрин писал(а):а тут есть пара пассов руками в компиляторе и Лазаре. Для различных библиотечных пакетов различается порядок путей, а следовательно имена одноименных модулей будут различны.

Допускаю, что сейчас сделали какой-то механизм, в котором каким-то образом умудряются подключить к одному проекту два пакета с одинаковыми именами модулей (надо будет попробовать проверить, хотя меня терзают смутные сомнения, что я получу ошибку). Но в штатной LCL такого нет, и это всё равно затруднительно. А даже если это и получается - то здесь и возникают массовые баги с поиском модулей, который часто натыкается на несовместимый.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 17.06.2017 10:33:25

daesher писал(а):Ну почему? Давайте посмотрим svn, там ничего откомпилированного нет. LCL 34,5 Мб, из них interfaces 26,8 (из которых мы берём только один, допустим, gtk2 1,9 Мб) - итого из lcl будет 9,6 Мб. Остаются совсем кусочки из components - это 3,9 Мб. Итого 13,5 Мб для сборки. Всего components занимают 67,9 Мб, но, допустим, кому-то там что-то надо.


Я не знаю как у вас получились такие суммы, но у меня папка, после всех описанных операций в свежескачаной версии транка, осталось 82,6Мб из 130. Большую часть занимает папка components -- 68,8Мб в из которой, на самом деле, ничего нельзя убрать, так как для нормальной компиляции может потребоваться все. Еще я оставил папку с изображениями, но это всего 4,51Мб, часть из которых нужна для компонент. Итого, все стертое занимает 47,4 Мб. Причем, я стер все интерфейсы, кроме одного, что в случае неправильного решения способно привести к непредсказуемым последствиям. (у меня, например, отказывала сборка определенных компонент)

И после всех этих манипуляций я не возьмусь гарантировать, что стер только ненужное для LCL for window.
ЗЫ: для справки, исходники самого компилятора занимают 936 МБ (с учетом потребностей файловой системы гиг.), так что проблема инсталляции и/или скачивания лазаруса это попытка сберечь пару копеек. Притом, что лазарус позволяет докачать дополнительные компоненты. Не стоит забывать, что для сборки транка лазаря(LCL) необходим транковый компилятор, который надо собирать обычным и который должен быть установлен в системе. (конечно, спорные компоненты могут быть и чисто внутренними, но тут лучше не рисковать ).

daesher писал(а): (из которых мы берём только один, допустим, gtk2 1,9 Мб)

Т. е. сознательно опускаетесь до уровня дельфи?


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


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

daesher писал(а):А даже если это и получается - то здесь и возникают массовые баги с поиском модулей, который часто натыкается на несовместимый.


Если все свалено в одной папке, то да. В противном случае компилятор может понять о каком файле речь. Если брать модуль System, то путь до него настраивается при выборе нужного виджета, а все остальные игнорируются.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 17.06.2017 10:59:27

Лекс Айрин писал(а):Я не знаю как у вас получились такие суммы, но у меня папка, после всех описанных операций в свежескачаной версии транка, осталось 82,6Мб из 130.

У меня из 156, но не суть.
Лекс Айрин писал(а):Большую часть занимает папка components -- 68,8Мб в из которой, на самом деле, ничего нельзя убрать, так как для нормальной компиляции может потребоваться все.

Во-первых, не всё: практически наверняка (если Вы не пишете новый lazarus) не потребуются codetools. Ещё несколько компонентов тоже актуальны только для IDE. Другие нужны сугубо в частных случаях.
Лекс Айрин писал(а):Вообще-то, каждый пакет это отдельный проект, который компилируется, в нормальном случае, по отдельности. Итоговый проект даже не знает о содержимом исходников пакетов.

В существующей ситуации пакет - это не какая-то модифицированная DLL, как в Delphi и Kylix, а всего лишь "обёрточная" структура для IDE, удобная для встраивания в Lazarus в виде компонентов и "подставляемая" компилятору в виде путей для поиска. Для компилятора технически - это всего лишь наборы модулей, не более того.
Лекс Айрин писал(а): В противном случае компилятор может понять о каком файле речь.

И каким же это образом? Компилятору "скармливается" (с помощью IDE или Lazbuild, не важно) набор из -Fu - путей до модулей пакетов (пусть даже уже скомпилированных). Если два пакета будут содержать по модулю с гениальным названием myunit.pas (и, как следствие, пару myunit.ppu+myunit.o), то каким образом компилятор, получив оба пути в -Fu, сможет догадаться, что, встретив в модуле проекта Unit1 "uses myunit", он должен подключить myunit из пакета Mypackage1, а в Unit2 в аналогичной ситуации - из пакета Mypackage2? (а что, если в одном модуле потребуется оба этих пакета и два одноимённых модуля?)
Лекс Айрин писал(а):Если брать модуль System, то путь до него настраивается при выборе нужного виджета, а все остальные игнорируются.

System - это немного другое. Он "набирается" из .inc, зависящих от конкретной платформы. Ни при каких обстоятельствах в него не должны попасть фрагменты из двух платформ сразу. Кстати, иногда подобные сбои происходили (и изредка происходят) - и в fpc, и в lazarus. Мы говорим как раз о ситуации, когда одному проекту нужно (прямо или косвенно) два одноимённых модуля. Что же касается "сбора" всего в один каталог - то идея кроссплатформенности теряется: для каждой платформы потребуется один, и только один набор всего (с другой стороны, используя такой "набор" на каждой платформе свой, мы можем уже собирать одинаковый проект на разных платформах). С другой стороны, в глючных и нестабильных версиях Lazarus удастся вручную "разрулить" нахождение несовместимых модулей.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 17.06.2017 13:05:27

daesher писал(а):практически наверняка (если Вы не пишете новый lazarus)


всякое может быть)))

daesher писал(а):Ещё несколько компонентов тоже актуальны только для IDE.


У меня нет списка гарантированно не используемых пользователем компонентов (тот же CodeTools, при желании, можно подключить к своей программе).

daesher писал(а):В существующей ситуации пакет - это не какая-то модифицированная DLL, как в Delphi и Kylix, а всего лишь "обёрточная" структура для IDE, удобная для встраивания в Lazarus в виде компонентов и "подставляемая" компилятору в виде путей для поиска.

Если не перекомпилировать, то как раз именно аналог DLL.

daesher писал(а): Для компилятора технически - это всего лишь наборы модулей, не более того.

технически, для компилятора, это объектный файл в формате удобном для встраивания.

daesher писал(а): Если два пакета будут содержать по модулю с гениальным названием myunit.pas (и, как следствие, пару myunit.ppu+myunit.o), то каким образом компилятор, получив оба пути в -Fu, сможет догадаться, что, встретив в модуле проекта Unit1 "uses myunit", он должен подключить myunit из пакета Mypackage1, а в Unit2 в аналогичной ситуации - из пакета Mypackage2? (а что, если в одном модуле потребуется оба этих пакета и два одноимённых модуля?)


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

daesher писал(а):System - это немного другое. Он "набирается" из .inc, зависящих от конкретной платформы. Ни при каких обстоятельствах в него не должны попасть фрагменты из двух платформ сразу.


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

daesher писал(а): С другой стороны, в глючных и нестабильных версиях Lazarus удастся вручную "разрулить" нахождение несовместимых модулей.


Честно говоря, эта фраза заставляет сомневаться в Вашей квалификации.

За все время работы я лишь раз десять, за несколько лет, встретил глючный и нестабильный лазарус и у меня ни разу не было ситуаций, когда в транке у меня полетели пути. Я мог неправильно собрать или собрать не той версией компилятора... у меня даже была ошибка в коде лазаруса временно исправленная, до обновления... Были случаи отказа в сборке из-за неправильного кода компонент. Несколько раз приходилось зачищать лазарус и ставить с нуля вместе с компилятором (как правило, при выходе свежей стабильной версии компилятора)... НО!!! Если компилятор/IDE собрались, то глюки были только в моем коде. Если нет, то значит приходилось ждать обновления (максимум неделю). И после перехода к прямому подключению к транку в SVN большая часть глюков пропала (до этого я использовал скачивание во временную папку).

Конечно, поддержка свежих версий компилятора/среды это тяжкий труд, но куда деваться -- все плюшки только в новых версиях. А старые версии постепенно становятся неактуальными. Если бы стабильные версии хотя бы обновлялись чаще(((
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 17.06.2017 19:01:31

Лекс Айрин писал(а):Если не перекомпилировать, то как раз именно аналог DLL.

dll и все его аналоги подключаются динамически. То есть, можно не перекомпилировать IDE, чтобы использовать компоненты (визуально), если 2 проекта используют пакет, то ни в одном из проектов код пакета не увеличит размер и т.п. Иначе - всего лишь аналог .lib/.a
Лекс Айрин писал(а):Элементарно. Для компиляции проектов важен порядок поиска модулей. То, что ближе к началу, главнее. Вначале модуль будет искаться в той же папке, потом в подпапках, а уже потом по остальным путям.
Плюс, есть возможность прямо указать откуда брать модуль, только ей стараются не пользоваться.

Всё это очень хорошо, когда для проекта есть два файла, из которых нужен только один. А когда нужно оба?
Но даже если нужен только один - как раз порядок поиска может случайно сбиться - поэтому так не любят делать одноимённые модули.
Лекс Айрин писал(а):System это обычный модуль, но подключаемый автоматически. И если глянуть на код многих пакетов нижнего уровня, то у них точно такая же ситуация с бутербродом из inc файлов и директив условной компиляции.

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

Прежде чем выдавать такое, надо знать, в чём заключается моя квалификация, без этого такие заявления - верх некорректности. Очевидно, что я не являюсь профессиональным программистом, хотя иногда и использую средства программирования как по работе, так и без неё. С другой стороны, я ни в коем случае не являюсь тем, кто боится хоть на шаг отступить от инструкции.
Лекс Айрин писал(а):За все время работы я лишь раз десять, за несколько лет, встретил глючный и нестабильный лазарус и у меня ни разу не было ситуаций, когда в транке у меня полетели пути. Я мог неправильно собрать или собрать не той версией компилятора... у меня даже была ошибка в коде лазаруса временно исправленная, до обновления... Были случаи отказа в сборке из-за неправильного кода компонент. Несколько раз приходилось зачищать лазарус и ставить с нуля вместе с компилятором (как правило, при выходе свежей стабильной версии компилятора)... НО!!! Если компилятор/IDE собрались, то глюки были только в моем коде

Вы говорите о последних паре лет (ну, пусть 5-7 годах). Я сталкиваюсь с Lazarus ещё до того, как вышел Kylix (и в те времена даже делал некоторые попытки участвовать в разработке; сейчас уровень, конечно, стал повыше, так что последние мои попытки "вмешательства" закончились периодом локализации - файлы lrt и DefaultTranslator, ныне - LCLTranslator - изначально моя идея, правда, от неё в коде уже мало чего осталось). Так вот - на заре Lazarus проблемы в поиске правильных модулей были от "каждого чиха", сбоил код обычных хеллоуворлдов, не говоря уж о чём-то сложнее. Потом был период, когда стабильный lazarus "застрял", а все пользовались svn-версией, которая тоже могла сбоить. И, наконец, сбои были очень частыми, пока не оказалась отработана система пакетов и зависимостей от них - периодически приходилось то прописывать пути как "дополнительные", то удалять их. Вот только после этого можно стало говорить, что если что не получается - проблема в коде или в настройках.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 19.06.2017 10:48:57

daesher писал(а):dll и все его аналоги подключаются динамически.


Есть еще предварительно скомпилированная библиотека статической линковки. Сейчас о них подзабыли, но в свое время они были очень популярны. Фактически, в лазарусе речь идет о них. И да, это аналог Lib, a и пр.

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

При "сырой версии" и пр.. компилятор/LCL просто не соберутся. А если компилятор не той версии... чтож... это не проблема компилятора/среды -- это проблема программиста.

daesher писал(а):Очевидно, что я не являюсь профессиональным программистом, хотя иногда и использую средства программирования как по работе, так и без неё.

Если честно, то тут мы примерно в одном положении -- официальной корочки программиста нет и у меня.

daesher писал(а):Вы говорите о последних паре лет (ну, пусть 5-7 годах).


А кого интересует история? Не стоит переносить ее на современное положение дел. Например, первая версия Опен Офиса была просто ужасна, я ее снес как бы даже не в тот же день... потом мне пришлось искать замену офису от майкрософт из-за его безобразно нестабильной работы и Опен Офис пошел на ура, он меньше зависал и случаи потери текста уменьшились на порядок.

daesher писал(а): Потом был период, когда стабильный lazarus "застрял", а все пользовались svn-версией, которая тоже могла сбоить.


Сейчас, насколько я знаю, все потихоньку переходят на транковую (svn) версию.

daesher писал(а): Так вот - на заре Lazarus проблемы в поиске правильных модулей были от "каждого чиха", сбоил код обычных хеллоуворлдов, не говоря уж о чём-то сложнее.


Это нормальное явление на заре любого программного продукта развивающегося стихийно.

daesher писал(а):файлы lrt и DefaultTranslator, ныне - LCLTranslator - изначально моя идея, правда, от неё в коде уже мало чего осталось

Если бы лично ВЫ чаще выкладывали код в сообщество, то, возможно, код быстрее пришел бы в норму. И, кстати, хорошо было встроить этот код прямо в лазарус, без подключения дополнительного модуля. Хотя и современный вариант хорош.

daesher писал(а):Всё это очень хорошо, когда для проекта есть два файла, из которых нужен только один. А когда нужно оба?


Так пакеты же разные и пути у них различные. Плюс, есть способ уточнить конкретно какой модуль имеется ввиду. Но не думаю, что это так важно, так как никто не будет так делать, а когда начнут, то этот вопрос разрулят обязательно (скорее всего, будет что-то типа [имя пакета].[имя модуля] так как данный вариант уже привычен и используется, например, в пакете Generics).

daesher писал(а):Но даже если нужен только один - как раз порядок поиска может случайно сбиться - поэтому так не любят делать одноимённые модули.


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

daesher писал(а):Прежде чем выдавать такое, надо знать, в чём заключается моя квалификация, без этого такие заявления - верх некорректности.


Честно скажу, здесь речь идет как раз о конкретно квалификации программиста в современной версии FPC. Все остальные Ваши знания лично мне перпендикулярны. Даже полгода перерыва для программиста это смерть. Лично мне пришлось, фактически, осваивать паскаль заново, хотя я старался следить за ситуацией. А ведь изначально я его знал довольно хорошо и приучил себя думать на паскале.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 23.06.2017 11:55:51

Лекс Айрин писал(а):Есть еще предварительно скомпилированная библиотека статической линковки. Сейчас о них подзабыли, но в свое время они были очень популярны. Фактически, в лазарусе речь идет о них. И да, это аналог Lib, a и пр.

Да, с ними аналогия есть. Правда, никаких плюсов в вопросах экономии памяти, дискового пространства они не дают, не говоря уж о невозможности динамического подключения.
Лекс Айрин писал(а):Если бы лично ВЫ чаще выкладывали код в сообщество, то, возможно, код быстрее пришел бы в норму.

Что тут сказать... Мой код, который "встраивался" в сам Lazarus, был, если так можно сказать, "грязным хаком". Чтобы довести его до уровня логичного встраиваемого кода, надо понимать всю "логику" IDE, а то и CodeTools. Ко времени, когда дело дошло до lrt, я уже всю эту логику "упустил", так что это было последнее, что я внёс, а "доведением до ума" занялись основные разработчики.
Впрочем, это более или менее характерно - править чужой код куда сложнее, чем делать свой.

Добавлено спустя 3 минуты 21 секунду:
Лекс Айрин писал(а): Но не думаю, что это так важно, так как никто не будет так делать, а когда начнут, то этот вопрос разрулят обязательно (скорее всего, будет что-то типа [имя пакета].[имя модуля] так как данный вариант уже привычен и используется, например, в пакете Generics).

Для этого пакет должен стать чем-то большим, чем просто конструкцией Lazarus. Он должен получить поддержку на уровне компилятора, скорее всего, это пойдёт параллельно с внедрением динамических пакетов (которые пока заброшены - хотя те же методы "грязного хака" позволяют собрать в dll практически всю LCL, а то и Classes.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 23.06.2017 12:04:58

daesher писал(а):Правда, никаких плюсов в вопросах экономии памяти, дискового пространства они не дают, не говоря уж о невозможности динамического подключения.


А много ли дает экономии инсталляция библиотек DLL на порядок большего размера, чем основная программа? А нормальная библиотека статической линковки выкидывает неиспользуемые части кода. Правда, сейчас все равно полно мусора. боюсь, что здесь придется очень долго оптимизировать, но пока никто не берется -- вроде как слишком много работы, по выпиливанию мертвого кода.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 23.06.2017 12:10:19

Лекс Айрин писал(а):А кого интересует история? Не стоит переносить ее на современное положение дел.

Переносить - не стоит, а вот помнить о ней - надо. Надо учитывать сильные и слабые стороны программного продукта, которые сложились исторически. Очень часто там, где раньше была слабая сторона, и сейчас (особенно в транке) выползают проблемы, пусть не на ровном месте, но когда возникает чуть более сложная задача. "Слабая сторона" Lazarus - это объективно запутанная система каталогов. Сейчас она всплывает, скорее, когда идут попытки кроссплатформенности, особенно с разными fpc. И да, ещё одна - разнообразие недоработанных интерфейсов. Более или менее поддерживаемые - win32 и gtk2 (но тоже не без проблем), чуть хуже - qt4.

Добавлено спустя 1 минуту 13 секунд:
Лекс Айрин писал(а):А много ли дает экономии инсталляция библиотек DLL на порядок большего размера, чем основная программа?

Если это не одна программа, а десяток маленьких утилит - то очень много. Да, в условиях, когда Lazarus - экзотика, которой пользуются для единичных проектов, которые, к тому же, имеют традиционную структуру - один проект - один исполняемый файл - экономия невелика, а если таких проектов будет много? А если для какого-то дистрибутива все "связующие" приложения (а то и часть базовых) писать на lazarus? В нём liblcl будет иметь чуть ли не больший смысл, чем libgtk, а libfpc - такой же, как и libstdc++
Последний раз редактировалось daesher 23.06.2017 12:18:20, всего редактировалось 1 раз.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 23.06.2017 12:17:27

daesher писал(а):Для этого пакет должен стать чем-то большим, чем просто конструкцией Lazarus. Он должен получить поддержку на уровне компилятора, скорее всего, это пойдёт параллельно с внедрением динамических пакетов


Я привел пример имени реально существующего пакета (Generics) в имени файлов которого уже используется данная нотация. И никаких грязных хаков нет.

daesher писал(а):хотя те же методы "грязного хака" позволяют собрать в dll практически всю LCL, а то и Classes


Это будет уже такая страшная магия, что пользоваться LCL будет невозможно. Уже сейчас "каст" срывается, если окно описано в DLL и подключено динамически. Для DLL и программы используются разные копии диспетчеров памяти и это приводит к непредсказуемым последствиям.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение daesher » 23.06.2017 12:26:15

Лекс Айрин писал(а):Я привел пример имени реально существующего пакета (Generics) в имени файлов которого уже используется данная нотация. И никаких грязных хаков нет.

В имени файлов. Это немного другое. Вопрос как раз в том, что будет, если есть два совсем одинаковых имени модуля.
Лекс Айрин писал(а):Это будет уже такая страшная магия, что пользоваться LCL будет невозможно. Уже сейчас "каст" срывается, если окно описано в DLL и подключено динамически. Для DLL и программы используются разные копии диспетчеров памяти и это приводит к непредсказуемым последствиям.

Да, если использовать существующие штатные средства FPC. Естественно, две копии менеджера памяти и много ещё чего (вплоть до LCL) - это не дело. Понятно, что нужно просто выделить "кусок" в dll/so, не дублируя его в исполняемом файле. Идеологически правильный подход - вставить этот механизм в компилятор, но мне удавалось обойтись без этого, "влезая" на этапе линковки путём махинации с link.res.
daesher
постоялец
 
Сообщения: 204
Зарегистрирован: 09.03.2010 22:17:14

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

Сообщение Лекс Айрин » 23.06.2017 12:38:45

daesher писал(а): "Слабая сторона" Lazarus - это объективно запутанная система каталогов. Сейчас она всплывает, скорее, когда идут попытки кроссплатформенности, особенно с разными fpc. И да, ещё одна - разнообразие недоработанных интерфейсов. Более или менее поддерживаемые - win32 и gtk2 (но тоже не без проблем), чуть хуже - qt4.


мне интересно, почему никто не хочет создать инструмент инкапсулирующий представление от реализации?

Запутанность каталогов это следствие синтетического подхода. Lazarus/FPC разделены на несколько слоев как минимум, на два: сама библиотека и низкоуровневый слой системно-аппаратной реализации. Так сказать, макро версия объектов.

daesher писал(а):Если это не одна программа, а десяток маленьких утилит - то очень много.


Лично у меня столько не наберется. Хотя комп набит под завязку разного рода программами настройки и проверки. Специализация. При том, что одних только .NET framework-ов четыре версии. А уж рунтаймовых библиотек от VC++весь десяток. По хорошему надо чистить, но боюсь удалять какую-либо версию чтобы не глюкнуло.

Добавлено спустя 10 минут 12 секунд:
daesher писал(а):В имени файлов.


Пока да. Но никто, на самом деле, не мешает сделать тоже и на уровне пакетов. Только лень и отсутствие необходимости.

daesher писал(а):Идеологически правильный подход - вставить этот механизм в компилятор, но мне удавалось обойтись без этого, "влезая" на этапе линковки путём махинации с link.res.


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

Конечно, речь идет не о встраивании подобного в компилятор, а о вмешательстве в процесс линковки.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

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

Сообщение Снег Север » 23.06.2017 13:03:08

daesher писал(а):Если это не одна программа, а десяток маленьких утилит - то очень много.
Вот! По одной этой фразе виден весь линуксятник... Плодить хералионы утилиток с невменяемым интерфейсом командной строки... Но тогда вопрос, который всплывал уже с самого начала - на хрена попу гармонь... нафига утилиткам командной строки LCL или иной графический интерфейс? Впрочем, к счастью, есть уже давно и вменяемая часть линуксойдов, которые делают графический оболочки для этих ... не стану говорить каких, утилиток так, что ими действительно можно пользоваться.
Аватара пользователя
Снег Север
энтузиаст
 
Сообщения: 949
Зарегистрирован: 27.11.2007 16:14:47

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

Сообщение Лекс Айрин » 23.06.2017 13:08:29

Снег Север, видимо он говорит о куче мелких графических утилиток в стиле "Сделать хорошо"... которые за собой тянут библиотеки поддержки то KDE, то Gnome... а то и еще какую экзотику.
Аватара пользователя
Лекс Айрин
долгожитель
 
Сообщения: 4097
Зарегистрирован: 19.02.2013 16:54:51

Пред.След.

Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: Google Adsense [Bot] и гости: 4

Рейтинг@Mail.ru