Пути к файлам в lazarus 0.9.30

[Сквозняк]

Установил методом научного тыка лазарус из rpm на платформу i686. Запустилось, работает, но вылезло из мешка давнее лазарусное шило: не понимает он символ * в путях( В результате, вместо /usr/lib/fpc/2.4.2/units/i386-linux/* нужно писать целую диссертацию или искать секретное окошко неизвестно как названное.

[Padre_Mortius]

Сквозняк
что-то вы не то делаете, вроде никакого шаманства не нужно для запуска Lazarus после установки из rpm

[Сквозняк]

А разве я писал про установку через yum? Не на каждом дистрибутиве есть он или rpm, да и лазарусные *.rpm сжаты новым архиватором, требующим неведомых обновлений. Это мейнтейнеры лазаруса не то делают, была бы установка бинарников из архива, как у fpc, то и проблем было бы меньше. Пришлось распаковать rpm на 64 битном дистрибутиве и скопипастить в 32 битном. fpc_crosswin32-2.4.2-110317.i386.rpm не ставил, попробую поставить. Из коммандной строки форма компилируется, маска /* работает, проблема с лазарусом.
С путями и раньше цирк был. В проекте несколько форм и каталог со сторонними исходниками, так приходится в свойствах каждой формы прописывать пачку закорючек. А здесь их будут уже десятки - одних исходников fpc недостаточно, лазарус требует ещё и модули.

[Padre_Mortius]

из rpm Lazarus давно не ставил, обычно из архива, но вроде бы там ничего сложного не было

Код: Выделить всё

rpm -Uvh lazarus....rpm

Буду дома проверю установку из rpm на Scientific Linux x86_64

Добавлено спустя 9 часов 12 минут 33 секунды:
Проверил установку из rpm пакета... Из нюансов только права нужно правильные выдать и разрешение на запись...

Не на каждом дистрибутиве есть он или rpm, да и лазарусные *.rpm сжаты новым архиватором, требующим неведомых обновлений

пользуюсь не самым свежим дистрибутивом... и никаких обновлений не требует... По поводу формата установочных пакетов на ftp://ftp.freepascal.org лежат и deb-файлы и архивы. Выбирайте, что вам нравится или что больше подходит для вашей системы.

Это мейнтейнеры лазаруса не то делают, была бы установка бинарников из архива, как у fpc, то и проблем было бы меньше

Я не знаю где вы искали, но вот лежат архивы с версией 0.9.30. Берите и собирайте сами.

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

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

Код: Выделить всё

samplecfg fpcdir confdir

А здесь их будут уже десятки - одних исходников fpc недостаточно, лазарус требует ещё и модули.

Что вы подразумеваете под модулями? Исходники компонент лазаря или библиотеку LCL?

[Сквозняк]

Проверил установку из rpm пакета... Из нюансов только права нужно правильные выдать и разрешение на запись...

Это на твоём конкретном дистрибутиве, а на многих других, не обновляемых длятельное время, утилита rpm потребовала обновлений. Распакуй пакеты и запакуй в tar.gz, после посмотри на размер, ты удивишься. Архиватор которым сжаты пакеты новый, без обновления ими не попользуешься.

По поводу формата установочных пакетов на ftp://ftp.freepascal.org лежат и deb-файлы и архивы. Выбирайте, что вам нравится или что больше подходит для вашей системы.

deb пакеты моему запасному дистрибутиву нужны как рыбе зонтик, а с архивами ментейнеры лазаруса прокатили по полной программе. Смотри http://freepascal.org/down/x86_64/linux-russia.var Вверху есть ссылка на 36 метровый дистрибутив фпц в архиве. Внутри лежат уже собранные бинарники и установочный скрипт. Часто пользуюсь именно такой расфасовкой паскаля. Никакие пакеты не дают мне такого удобства, когда нужно поставить несколько версий в /home/user/fpc* Причём, в теперешнем моём дистрибутиве rpm установлен самостоятельно, yum глючит из-за питона(я его не знаю настолько чтобы исправить все баги) - дистр ведь на базе генты

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

которые лежат рядом с исходниками программы

Вот, нужно лить файлы из разных проектов и библиотек в один каталог как в помойку, а когда их наберётся больше сотни, случится ахтунг. Если компилировать из коммандной строки или иде паскаля, то можно в каталог лить не файлы, а каталоги с файлами, после указать все-лишь _один_ путь с маской /* и всё будет работать. Иде лазаруса так не умеет, вот что мне нужно писать в параметрах компилятора каждого проекта, а их как видно из кода 5 штук:

Код: Выделить всё

../../;../2/;../3/;../4/;../5/

А если таких записей будет сотня? Подозреваю, что сейчас на 32 битном дистрибутиве кривовато установился фпц - лезет к модулям от предыдущей версии, хотя должен находить свои. В ИДЕ паскаля достаточно указать _один_ путь с маской и всё нормально работает, поэтому данное недоразумение даже не рассматривалось как какой-то баг. Но в лазарусном иде нельзя указать каталог с каталогами модулей, только конкретный конечный каталог. Искать, почему компилятор фпц не находит свои модули автоматически, довольно муторно, проще подсунуть ему туда, где он найдёт их в первую очередь. Но всё равно, это не отменяет недоработки в иде лазаруса, нужна маска /* в путях к исходникам и модулям.

Что вы подразумеваете под модулями? Исходники компонент лазаря или библиотеку LCL?

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

[daesher]

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

Для компилятора исходники совершенно не нужны, они нужны для IDE - для обработки кода. Как он ещё может определить, куда можно влепить обработчик события, если он понятия не имеет, какой это компонент, что это за класс? О завершении кода я не говорю. Т.е., перерабатывая код, IDE (точнее, CodeTools) перелопачивают все модули до самого начала (т.е., например, работая с потомком TForm, опускаются вплоть до описания TObject), при этом ищут всё по исходникам, а не бинарникам модулей. Как я понимаю, Delphi обрабатывает уже откомпилированные модули (dcu); в теории, в модулях PPU уже всё есть, только потеряется регистр; было бы, конечно, неплохо написать декомпилятор интерфейсной части таких модулей и прикрутить к CodeTools, тогда исчезла бы зависимость от исходников FPC и даже Lazarus (впрочем, до появления Library Package он будет нужен для пакетов), что, как минимум, сэкономит память. Конечно, это "облегчит задачу мировому злу" - закрытому коду, но усложнять ему путь можно и нужно другими способами, нежели создавать проблемы пользователям.

[Сквозняк]

Как я понимаю, Delphi обрабатывает уже откомпилированные модули (dcu); в теории, в модулях PPU уже всё есть, только потеряется регистр; было бы, конечно, неплохо написать декомпилятор интерфейсной части таких модулей и прикрутить к CodeTools, тогда исчезла бы зависимость от исходников FPC и даже Lazarus (впрочем, до появления Library Package он будет нужен для пакетов), что, как минимум, сэкономит память.

Пожалей разработчиков, им некогда полезные фичи реализовывать(да хотя бы прикрутить int64 в цикле for на 32 битной платформе), а ты хочешь напрячь их на разбор модулей для каждой платформы. Паскаль, в отличии от дельфи, работает на куче платформ и их количество склонно расти, а следом за ним туда проникает и лазарус. Проблема экономии памяти пусть беспокоит программистов с планшетниками. На ПК с линуксом иметь лишнюю память полезно хотя бы для дискового кэша. Он реально помогает, время второй компиляции исходников на паскале обычно меньше раза в два. Поэтому, на оперативке лучше сильно не экономить.

[daesher]

Платформы, конечно - дело серьёзное, но я не уверен, что код именно .ppu очень сильно отличается в рамках платформ (вот .o - другой разговор, но он и не нужен). Где-то даже были инструменты для расшифровки ppu (правда, это не декомпиляция, так что напрямую к codetools прикрутить их не выйдет).
Экономия памяти (как оперативной, так и дисковой) - дело важное и нужное, и в этом отношении FPC и особенно Lazarus много чего стоит сделать (и, я думаю, это - главная проблема, всё остальное уже есть). То, что памяти хватает на средних машинах - не аргумент, т.к. есть и более старые (кстати, на моём рабочем ноутбуке, главный принцип которого - "чтобы не жалко было", FPC вешает linux подчистую, причём не очень предсказуемо). И это при том, что года 3 назад всё прекрасно работало (особенно это относится версии FPC 1.0.х). Я считаю, что подход "накидать фич, и не оптимизировать" - изначально губительный. Впрочем, размер Lazarus растёт не очень сильно. А планшетники... Это - тоже компы. И именно они показали губительность подхода. А отмахнуться от них - это как бороться с термометром при высокой температуре.
Разработка чтения модулей - важная стадия (кстати, именно требование наличия исходников принципиально выбивает lazarus из всех остальных программ, в т.ч. и под linux - получается гибрид исходника и бинарника, в итоге столько вопросов по установке, хотя, конечно, "костыли" уже сделаны).
IMHO, приоритет следующий:
1. Доработка Library Package и выброс (пока опциональный) RTL и LCL в библиотеки (.so/.dll)
2. Создание расшифровщика .ppu (возможно, используя имеющиеся; возможно, есть сторонние наработки) и прикручивание его к CodeTools (опционально: если не находится исходник, расшифровывается .ppu).
3. Прикручивание Library Package к системе пакетов Lazarus (после этого можно будет полностью разделить бинарные пакеты и исходные коды)\

0. Постоянная оптимизация на всех этапах; создание альтернативных мини-версии RTL и LCL (прежде всего, MiniClasses; возможно, выделение принципиально разных классов в отдельные модули); оптимизация компилятора для работы на системах с "малой" памятью - 256 Мб (512 - уже мало, а в 2003 это было ОЧЕНЬ много).