Делюсь небольшим опытом по портированию большого проекта на Linux. Может кому пригодится.

https://yadi.sk/d/h7LJ2N58v0aWdQ

rgreat,

Спасибо за оценку !

sql2012,

Три В. Сериал конечно тот прикольный был, смотрел когда-то давно.

ъъъъъ,

Вы можете дополнить документ своими мыслями в конце.

Fr0sT-Brutal,

Многое там было сделано не оптимально и на скорую руку. Классы я не переименовывал из принципа, чтобы потом Delphi при редизайне форм не давало сбои.

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

DmSer,

На линуксе тестируем у заказчика для воспроизведения видеокадров управления на стойке системы регулирования для АЭС. Основная версия виндовая. Но сейчас институты поджимают с линукс версией и некоторые промышленные заказчики.

DmSer,

А у меня сейчас и для Delphi и для CT одна кодовая база и один репозиторий. В принципе основные изменения идут в невизуальной части программы (допиливание библиотек расчётных новых, исправление ошибок).
dfm-файлы меняем редко, соотвественно конвертировать их в frm тоже приходится редко. Максимум что было это изменения состава контекстного меню в некоторых местах.
Там есть 2 места несколько проблемных при конвертации dfm файлов, где пришлось просто вырезать руками потом сконвертированный текст в файле. А остальное было без изменений вообще - там использовались стандартные компоненты.
При изменении в невизуальной части если это не системно-зависимый код, оно автоматом работает и в CT - только надо аккуратно generic-и применять в ряде мест для совместимости. У меня за последнее время таких мест было много и вроде как с поддержкой проблем особых не возникло.
При изменении структуры формы в Delphi - повторная конвертация в CT (беру dfm и натравливаю на него штатный конвертор CT), потом ревизия изменений через GIT и если надо корректировка дизайна. Контролы GTK от виндовых изрядно отличаются, и бывает что нужно подвинуть их, но это редко бывает.
На ближайшие года 3 мы планируем использовать для Windows - Delphi, для Linux - CT. Потом как видно будет, но мне лично и коллективу пока так удобнее. Сейчас фактически я и там и там код пишу и мержу его потом в одну кодовую базу а потом собираю в разных местах.

asutp2,

Программа исходно - VCL и пишется более 15 лет.
FMX рассматривали, но там в ряде мест сильно отличается код при работе с графикой. Менять что-то под Windows не хотелось вообще - то есть там у меня всё было сохранено как есть. И поэтому портировать оказалось проще на LCL - меньше был объем изменений исходного кода. Ну и отладку было тоже удобнее производить непосредственно на Linux машине (Alt Linux или Astra Linux ну еще на Suse проверял). У меня есть подозрение что с FMX я бы больше проблем поимел так как там надо было виндовый работающий код корректировать, а так нормально получилось вполне - и под Windows работает как положено и на Linux вроде.

Сергей Фролов,

web-интерфейс просило начальство у заказчиков некоторых. А программа рассчитана на работу на инженерных рабочих станциях с определёнными задачами - это моделирование динамики АЭС (ну и других объектов). По функционалу - это аналог Simulink, только с дополнительными возможностями в виде проектирования и расчёта теплогидравлических сетей и возможности создания комплексных динамических моделей энергоблоков АЭС + видеокадров управления.

Чтобы реализовать систему с web-интерфейсом полноценным её надо сильно перепроектировать, что в задачу пока не входит. Хотя как вариант можно встроить web-сервер в качестве плагина, для того, чтобы просматривать схемы модели на удалённых машинах. В SVG их сохранять она умеет если что.

DmSer,

Я писал на адрес Бернеде, но видимо почта нерабочая или в спам ушло. Мы ихние официальные покупатели были, попробуем на оф. почту отправить.