Binary Packages - не пора ли их реализовать?
Модератор: Модераторы
Binary Packages - не пора ли их реализовать?
Хотя сложности конечно есть.
Первая проблема в контроле версий собранных пакетов - это общая проблема динамических библиотек (решения тоже существуют для обычных библиотек в Windows ввели SxS, в Линуксе это решается через управление версиями в репозиториях. Но первый вариант привязан к винде и фактически сводится к хранению всех версий установленных библиотек, а второй требует четкой обратной совместимости и видимо не реализуем в случае ООП).
Сделать пакеты не зависимыми от ОС можно если формат использовать свой или один для всех систем (выбрать например ELF) и грузить пакеты вручную.
(собственно сам машинных код зависит только от процессора а не от ОС)
Независмость от целевой архитектуры уже не получится - тут только что-то наподобие FatELF (когда внутри файла есть код для всех платформ) но пакеты получатся большими, но не на столько - процессорных архитектур не так много.
Остается RTL (и не только а весь не полностью кроссплатформенный код) - с ней сложнее - большинство кода не переносимо. Тут я вижу 2 варианта: либо весь код RTL линковать прямо в исполнимый файл, либо делать сборки для каждой платформы отдельно (главное в обоих случаях обеспечить совместимость интерфейсов).
Первая проблема в контроле версий собранных пакетов - это общая проблема динамических библиотек (решения тоже существуют для обычных библиотек в Windows ввели SxS, в Линуксе это решается через управление версиями в репозиториях. Но первый вариант привязан к винде и фактически сводится к хранению всех версий установленных библиотек, а второй требует четкой обратной совместимости и видимо не реализуем в случае ООП).
Сделать пакеты не зависимыми от ОС можно если формат использовать свой или один для всех систем (выбрать например ELF) и грузить пакеты вручную.
(собственно сам машинных код зависит только от процессора а не от ОС)
Независмость от целевой архитектуры уже не получится - тут только что-то наподобие FatELF (когда внутри файла есть код для всех платформ) но пакеты получатся большими, но не на столько - процессорных архитектур не так много.
Остается RTL (и не только а весь не полностью кроссплатформенный код) - с ней сложнее - большинство кода не переносимо. Тут я вижу 2 варианта: либо весь код RTL линковать прямо в исполнимый файл, либо делать сборки для каждой платформы отдельно (главное в обоих случаях обеспечить совместимость интерфейсов).
Пора. Займитесь.
- Nik
- энтузиаст
- Сообщения: 573
- Зарегистрирован: 03.02.2006 23:08:09
- Откуда: Киров
- Контактная информация:
Может немного не в тему, но... Где-нибудь опубликованы хотя бы примерные планы разработчиков на версии после 1.0 (в частности - планы по развитию, с исправлением ошибок-то всё ясно - багрекер на виду)?
Максим писал(а):Пора. Займитесь.
Уже занялся
- Nik
- энтузиаст
- Сообщения: 573
- Зарегистрирован: 03.02.2006 23:08:09
- Откуда: Киров
- Контактная информация:
Odyssey
Это всё про FPC, а мне интересен именно Lazarus. Вот, например, раз уж речь зашла, не планируют ли сделать свой дебаггер в будущем, чтобы сделать exe-файлы поменьше без ущерба для отладки? Или сабжевые бинарные пакеты добавить? В общем, в эту сторону. У FPC линия развития вполне прослеживается - они на компилятор Delphi ориентируются.
Это всё про FPC, а мне интересен именно Lazarus. Вот, например, раз уж речь зашла, не планируют ли сделать свой дебаггер в будущем, чтобы сделать exe-файлы поменьше без ущерба для отладки? Или сабжевые бинарные пакеты добавить? В общем, в эту сторону. У FPC линия развития вполне прослеживается - они на компилятор Delphi ориентируются.
Собственный отладчик и бинарные пакеты -- это как раз не к Lazarus, а к FPC. Эти фичи завязаны именно на возможности компилятора.
