CPPLASTIC Telegram 466
Ну добре, годі тягнути кота за хвіст. Я вже писав, як ми втомилися від Qbs, писав про інші системи, які ми спробували. І врешті-решт я зупинив свій вибір на Xmake.

Як і Premake, ця система базується на 💻, але на цьому спільні риси закінчуються. Чи закриває Xmake усі мої потреби? Абсолютно ні. У ньому купа недоліків. Попри це він задовольняє деякі з моїх критеріїв, які мені критично важливі, і я вважаю, що цей компроміс того вартий.

В Xmake уже є підтримка збирання 💻-програм, але вона вкрай кепська: якоюсь мірою працює для умовного Hello World, але не для повноцінної програми. Нам довелося написати декілька власних правил — і наскільки ж це легше робити, ніж у Qbs! Хоча прихованих проблем теж удосталь. За той місяць, протягом якого ми вʼяло колупаємо Xmake, я вже зарепортив декілька багів і створив низку запитів на фічі.

Шила в мішку не втаїш, тому одразу зазначу один з найпомітніших нюансів щодо розробки Xmake… Це китайський продукт 🙂 Тому на ґітгабі нерідко можна побачити тікети на кшталт отакого: xmake在mingw下无法编译. Не кривитиму душею — це трохи лякає. Не хотілося б, щоб воно збирало програму разом зі вбудованим бекдором 😅 З іншого боку декілька багів, які я знайшов, я сам же й виправив. А ті, шо не виправив, автор пофіксив сам протягом доби-двох. Отже, до цього взагалі жодних нарікань: сирці зрозумілі, виправляти не складно, на ревʼю тільки валідні коментарі — все швидко й адекватно.

Опис білда на Xmake переважно декларативний, але можна (інколи треба) й імперативні скрипти писати. Є підтримка різних компіляторів і навіть мов, є якась підтримка модулів з C++20, усілякі там віддалені й розподілені білди, кому треба, створення пакетів з готовими програмами тощо.

Одна з найвагоміших переваг Xmake — я нарешті зміг позбутися всратого Conan, бо в Xmake є вбудований менеджер пакетів з централізованим сховищем, але й створити власне дуже легко — це просто 💻-репозиторій. Я вже створив окреме для наших бібліотек. До речі, якщо пакет збирається чимось іншим, наприклад, тим же сімейком, то це не проблема — все легко інтегрується.

Інша вагома перевага: можна створити пакет з кастомними правилами для збирання. Саме це я й намагаюся робити, бо мене замахало їх копіпастити між проєктами. Потім в одному щось покращив, в інший не переніс, і навпаки… Дуже дратує. А тепер я можу просто додати залежність на правила — і жодного головного болю від ґіт-сабмодулів або ще чогось. Ну, принаймні в теорії, бо на практиці того ідеалу, що в мене в голові, я ще не досяг.

Зараз я вже бачу, що багато з того, що мені треба, в Xmake відсутнє. Не було правил для автоматичної генерації Qt-ресурсів, qmldir-файлів, компіляції шейдерів (це ми написали все), немає підтримки InnoSetup, AppImage або Flatpak, macOS DMG тощо. З іншого боку я нарешті бачу шлях, як це написати власноруч, не чекаючи, що хтось з розробників системи збирання це зробить.

З документацією все теж складнувато: багато важливих і корисних штук там взагалі не описані. Зате сирці читати доволі легко, адже мови, простішої за Lua, ще не вигадали.

Звісно, є відчуття, що я проміняв одну мутну систему на іншу. Типу, чого б уже просто не взяти CMake 🤮‽ Але у підсумку мені здається, що якраз-таки цей вибір був дуже прагматичним. І попри купу недоліків, мої потреби Xmake закриває краще.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🥴2🤣1



tgoop.com/cpplastic/466
Create:
Last Update:

Ну добре, годі тягнути кота за хвіст. Я вже писав, як ми втомилися від Qbs, писав про інші системи, які ми спробували. І врешті-решт я зупинив свій вибір на Xmake.

Як і Premake, ця система базується на 💻, але на цьому спільні риси закінчуються. Чи закриває Xmake усі мої потреби? Абсолютно ні. У ньому купа недоліків. Попри це він задовольняє деякі з моїх критеріїв, які мені критично важливі, і я вважаю, що цей компроміс того вартий.

В Xmake уже є підтримка збирання 💻-програм, але вона вкрай кепська: якоюсь мірою працює для умовного Hello World, але не для повноцінної програми. Нам довелося написати декілька власних правил — і наскільки ж це легше робити, ніж у Qbs! Хоча прихованих проблем теж удосталь. За той місяць, протягом якого ми вʼяло колупаємо Xmake, я вже зарепортив декілька багів і створив низку запитів на фічі.

Шила в мішку не втаїш, тому одразу зазначу один з найпомітніших нюансів щодо розробки Xmake… Це китайський продукт 🙂 Тому на ґітгабі нерідко можна побачити тікети на кшталт отакого: xmake在mingw下无法编译. Не кривитиму душею — це трохи лякає. Не хотілося б, щоб воно збирало програму разом зі вбудованим бекдором 😅 З іншого боку декілька багів, які я знайшов, я сам же й виправив. А ті, шо не виправив, автор пофіксив сам протягом доби-двох. Отже, до цього взагалі жодних нарікань: сирці зрозумілі, виправляти не складно, на ревʼю тільки валідні коментарі — все швидко й адекватно.

Опис білда на Xmake переважно декларативний, але можна (інколи треба) й імперативні скрипти писати. Є підтримка різних компіляторів і навіть мов, є якась підтримка модулів з C++20, усілякі там віддалені й розподілені білди, кому треба, створення пакетів з готовими програмами тощо.

Одна з найвагоміших переваг Xmake — я нарешті зміг позбутися всратого Conan, бо в Xmake є вбудований менеджер пакетів з централізованим сховищем, але й створити власне дуже легко — це просто 💻-репозиторій. Я вже створив окреме для наших бібліотек. До речі, якщо пакет збирається чимось іншим, наприклад, тим же сімейком, то це не проблема — все легко інтегрується.

Інша вагома перевага: можна створити пакет з кастомними правилами для збирання. Саме це я й намагаюся робити, бо мене замахало їх копіпастити між проєктами. Потім в одному щось покращив, в інший не переніс, і навпаки… Дуже дратує. А тепер я можу просто додати залежність на правила — і жодного головного болю від ґіт-сабмодулів або ще чогось. Ну, принаймні в теорії, бо на практиці того ідеалу, що в мене в голові, я ще не досяг.

Зараз я вже бачу, що багато з того, що мені треба, в Xmake відсутнє. Не було правил для автоматичної генерації Qt-ресурсів, qmldir-файлів, компіляції шейдерів (це ми написали все), немає підтримки InnoSetup, AppImage або Flatpak, macOS DMG тощо. З іншого боку я нарешті бачу шлях, як це написати власноруч, не чекаючи, що хтось з розробників системи збирання це зробить.

З документацією все теж складнувато: багато важливих і корисних штук там взагалі не описані. Зате сирці читати доволі легко, адже мови, простішої за Lua, ще не вигадали.

Звісно, є відчуття, що я проміняв одну мутну систему на іншу. Типу, чого б уже просто не взяти CMake 🤮‽ Але у підсумку мені здається, що якраз-таки цей вибір був дуже прагматичним. І попри купу недоліків, мої потреби Xmake закриває краще.

BY Cіпласпластик




Share with your friend now:
tgoop.com/cpplastic/466

View MORE
Open in Telegram


Telegram News

Date: |

Joined by Telegram's representative in Brazil, Alan Campos, Perekopsky noted the platform was unable to cater to some of the TSE requests due to the company's operational setup. But Perekopsky added that these requests could be studied for future implementation. 3How to create a Telegram channel? The creator of the channel becomes its administrator by default. If you need help managing your channel, you can add more administrators from your subscriber base. You can provide each admin with limited or full rights to manage the channel. For example, you can allow an administrator to publish and edit content while withholding the right to add new subscribers. A vandalised bank during the 2019 protest. File photo: May James/HKFP. The initiatives announced by Perekopsky include monitoring the content in groups. According to the executive, posts identified as lacking context or as containing false information will be flagged as a potential source of disinformation. The content is then forwarded to Telegram's fact-checking channels for analysis and subsequent publication of verified information.
from us


Telegram Cіпласпластик
FROM American