The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск сборочной системы Meson 0.51

17.06.2019 09:56

Опубликован релиз сборочной системы Meson 0.51, которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK+. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0.

Ключевой целью развития Meson является обеспечение высокой скорости сборочного процесса в сочетании с удобством и простотой использования. Вместо утилиты make при сборке по умолчанию применяется инструментарий Ninja, но возможно применение и других бэкендов, таких как xcode и VisualStudio. В систему встроен многоплатформенный обработчик зависимостей, позволяющий использовать Meson для сборки пакетов для дистрибутивов. Правила сборки задаются на упрощённом предметно-ориентированном языке, отличаются хорошей читаемостью и понятны пользователю (по задумке авторов разработчик должен тратить минимум времени на написание правил).

Поддерживается кросс-компиляция и сборка в Linux, macOS и Windows с использованием GCC, Clang, Visual Studio и других компиляторов. Возможна сборка проектов на различных языках программирования, включая C, C++, Fortran, Java и Rust. Поддерживается инкрементальный режим сборки, при котором пересобираются только компоненты, напрямую связанные с изменениями, внесёнными с момента прошлой сборки. Meson можно использовать для формирования повторяемых сборок, при которых запуск сборки в разных окружениях приводит к генерации полностью идентичных исполняемых файлов.

Основные новшества Meson 0.51:

  • Добавлена поддержка прозрачной сборки существующих проектов, в которых используются сборочные сценарии CMake. Meson теперь напрямую может собирать простые субпроекты (такие как одиночные библиотеки) с использованием модуля CMake по аналогии со штатными субпроектами (в том числе субпроекты на CMake могут размещаться в каталоге subprojects );
  • Для всех применяемых компиляторов включено предварительное тестирование через сборку и исполнение простейших тестовых файлов (sanity check), не ограничиваясь тестированием указанных пользователем флагов для кросс-компиляторов (отныне проверяются и родные для текущей платформы компиляторы).
  • Добавлена возможность определения опций командной строки, применяемых при кросс-компиляции, с привязкой через задание префикса платформы перед опцией. Ранее опции командной строки охватывали только сборку для родной платформы и не могли указываться для кросс-компиляции. Теперь опции командной строки применяются независимо от того осуществляется нативная сборка или кросс-компиляция, гарантируя, что для нативных и кросс-сборок будет получен идентичный результат;
  • Добавлена возможность указания флага "--cross-file" более одного раза в командной строке для перечисления нескольких cross-файлов;
  • Добавлена поддержка компилятора ICL (Intel C/C++ Compiler) для платформы Windows (ICL.EXE и ifort);
  • Добавлена начальная поддержка инструментария для CPU Xtensa (xt-xcc, xt-xc++, xt-nm);
  • В объект "dependency" добавлен метод "get_variable", позволяющий получить значение переменной без учёта типа текущей зависимости (например, dep.get_variable(pkg-config : 'var-name', cmake : 'COP_VAR_NAME));
  • Добавлен новый аргумент параметров целевой сборки - "link_language" для явного определения языка, используемого при вызове компоновщика. Например, основная программа на Fortran, может вызывать код на C/C++, что приведёт к автоматическому выбору C/C++, в том время как нужно использовать компоновщик от Fortran;
  • Изменена обработка флагов препроцессора CPPFLAGS. Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживают;
  • Вывод custom_target и custom_target[i] теперь может использоваться в качестве аргументов в операциях link_with и link_whole;
  • В генераторах добавлена возможность задания дополнительных зависимостей при помощи опции "depends" (например, generator(program_runner, output: ['@BASENAME@.c'], depends: exe));
  • В find_library добавлена опция static для охвата поиском только статически связанных библиотек;
  • Для python.find_installation добавлена возможность определения наличия заданного Python-модуля для конкретной версии Python;
  • Добавлен новый модуль unstable-kconfig для разбора файлов kconfig;
  • Добавлена новая команда "subprojects foreach", принимающая команду с аргументами и запускающая её во всех каталогах субпроектов;


  1. Главная ссылка к новости (https://groups.google.com/foru...)
  2. OpenNews: Выпуск сборочной системы Meson 0.50
  3. OpenNews: Компания Google представила первый выпуск открытой системы сборки Bazel
  4. OpenNews: Разработчик языка XL опубликовал новую сборочную систему build
  5. OpenNews: Проект Qt прекращает разработку сборочной системы Qbs в пользу CMake
  6. OpenNews: Релиз системы сборки CMake 3.14
Лицензия: CC-BY
Тип: Программы
Ключевые слова: meson, build
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (64) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
 
  • 2.9, Аноним (9), 12:14, 17/06/2019 [ответить]  
  • –4 +/
    Gn — это интерпритатор неких скриптов, не знающих ничего ни о компиляторах, ни о флагах, ни о размещении либ. Вся эта информация хранится в скриптах, которые лежат внутри Хромиума. Хочешь собрать Хелло Ворлд, выкачивай исходники всего Хромиума. А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах, они то ничего не знают о твоем проекте и никому не гарантируют неизменность своих скриптов.

    О да, лучшая сборочная система.

     
     
  • 3.22, Аноним (22), 13:21, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хочешь собрать Хелло Ворлд, выкачивай исходники всего Хромиума

    Бред какой-то несешь. Каноничный и полный хелловорлд приводится самим же гуглом вот тут:

    https://gn.googlesource.com/gn/+/master/tools/gn/example

    > А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах

    Как гугловцы поломают что-то в моих же скриптах? Опять-таки, в тебе говорит незнание матчасти и убежденность, будто нужны полные исходники хромиума. GN сам по себе минимален, все остальное (включая поддержку pkgconfig и тому подобное) лежит в дереве исходников хромиума. Копируй их себе в проект, удаляй всё, что тебе не надо, подправляй остальное под свои нужды, и всё -- ты независим от гугла.

     
     
  • 4.34, Аноним (34), 18:33, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А можно было бы включить наиболее востребованные скрипты в дистрибутив и поддерживать в них обратную совместимость… Хотя стоп, это же cmake получится.
     
     
  • 5.41, Аноним (22), 20:42, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Можно конечно Я вообще разработчикам предлагал в GN засунуть не только востребо... текст свёрнут, показать
     
     
  • 6.56, Аноним (34), 10:30, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, не надо передёргивать. Во-вторых, с rpm-макросами всё обстоит точно так же, как с модулями cmake: наиболее востребованные идут в комплекте, специфические поставляются вместе с соответствующим софтом.
     
  • 1.4, menangen (?), 10:50, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Пробовал, понравилась эта система сборки, но на продакшен так и не попала ни в одном проекте, увы. Её бы переписать на Go в один бинарник, это было бы интересно...
     
  • 1.5, Аноним (5), 11:10, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    помню, как тут все плевались с этого мезона. "Нинужно" и т.п.

    а сейчас ничего - все пользуются

     
     
  • 2.7, Аноним (7), 11:41, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Кто - все? Питон обязателен - значит "нeнужно". Я ещё не совсем спятил, чтобы заставлять пользователей ставить питон и зависимые либы только ради мезона.
     
     
  • 3.10, IRASoldier_registered (ok), 12:20, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Питон обязателен - значит "нeнужно"

    Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?

     
     
  • 4.13, Аноним (13), 12:34, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > ну считайте, что Python это just another ***sh.

    Вот только не надо про то, что это shall. В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox). А в питонах, где ни запустишь, ловишь дичь какую-то из-за несовместимостей версий. Язык должен быть железным как bash или Ruby. Или, сразу, бинарный код.

     
     
  • 5.14, IRASoldier_registered (ok), 12:37, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >или Ruby

    Вот не в курсе, что там у рубистов - у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?

     
     
  • 6.19, Аноним (-), 12:52, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  у Ruby разве нет проблем с совместимостью версий

    куда больше, чем у питона, вы с сумашедшим общаетесь, если он этого не осознает

     
  • 6.24, Аноним (-), 13:52, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?

    Довольно редко. Обычно раз в 5-10 лет это происходит. Да и то, по мелочам.

     
  • 5.18, Аноним (34), 12:46, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox).

    В busybox нет bash, там ash. В минимальных установках ряда дистрибутивов тоже может не быть bash.

     
  • 5.27, Пони (?), 16:10, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Удачи с обновлением скриптов на баш 5.
     
  • 5.32, Аноним (32), 17:39, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В Bash я могу быть уверен

    Ааааага. Давайте ка вы будете уверены в sh. А вот его жирненький дружочек bash таки разный от дистра к дистру. Где-то есть, где лежит не в том каком-то месте, а где-то его и нет (и это нормально).

     
  • 4.16, Аноним (34), 12:44, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Башем-то пользуетесь, и не паритесь, что он установлен

    Когда надо — паримся и пишем на POSIX shell.

     
  • 4.23, freehck (ok), 13:48, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?

    Да, потому что shell для административных задач -- куда более удобный инструмент. shell-скрипты меньше по объёму и как правило более-менее хорошо написаны, в то время как любой python-скрипт огромен по размеру и склонен быть глюкодромом. И по-видимому, весьма много людей так или иначе столкнулись с плохим поведением python и хорошим поведением shell.

    Это, безусловно, субъективный опыт. Если хотите, мы можем поспорить на тему python vs shell, и в процессе составить табличку плюсов и минусов. Это будет хорошая замашка на объективность.

     
     
  • 5.26, Gvd57uvx4 (?), 15:28, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Для себя взял за правило вотэтовот >>>

    Bash использую до 40 строк.
    Python использую от 40 строк.

     
     
  • 6.39, Аноним (39), 20:17, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут больше от наличия/сложности логики зависит, чем от размера. Если нужно последовательно запустить 100 программ с параметрами, баш лучше подойдет, а если какая-то математика или работа со строками, то и от 40 строк на баше удавишься
     
     
  • 7.43, Аноним (34), 23:08, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > если какая-то математика или работа со строками, то и от 40 строк на баше удавишься

    Это ещё смотря что за работа со строками.

     
  • 7.71, Michael Shigorin (ok), 19:18, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут больше от наличия/сложности логики зависит, чем от размера.

    А у меня -- от необходимой сложности структур данных и наличия готовых библиотек (кстати, кто не знал, угощайтесь: http://altlinux.org/libshell).

     
     
  • 8.73, Аноним (34), 00:46, 19/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, обойдёмся ... текст свёрнут, показать
     
  • 5.62, Аноним (34), 11:44, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > shell-скрипты меньше по объёму и как правило более-менее хорошо написаны

    Или ты ничего не понимаешь в шелл-скриптах, или просто не смотришь на скрипты, написанные другими. Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.

     
     
  • 6.67, freehck (ok), 15:57, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.

    Это специфично для программирования в целом. Подставьте вместо "shell" любой другой язык -- и это тоже будет правдой.

     
  • 3.30, Аноним (30), 17:28, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Питон обязателен - значит "нeнужно".

    Вообще, разработчики meson говорили пару раз, что чисто в теории можно и без python. Но есть два но... Сейчас система сборки еще не устаканилась и фичи постоянно добавляются, поэтому прямо сейчас отвязывать бессмысленно. Сами разработчики не заинтересованы в отвязывании от питона, но кто-нибудь другой может заняться.

     
     
  • 4.40, Аноним (39), 20:20, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А зачем отвязывать, чтобы усложнить разработку и повысить порог вхождения для контрибьюторов? cmake вон написали на крестах, получилась говнистая архитектура, в которой левая нога не знает, что правая делает, и нужно придумывать всякую дичь вроде generator expressions, чтобы это скомпенсировать
     

  • 1.6, Аноним (-), 11:35, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Чем вам configure && make && sudo checkinstall не угодил? Мало смузи?
     
     
  • 2.12, Michael Shigorin (ok), 12:28, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > sudo checkinstall

    В другую-то крайность кидаться не надо...

     
     
  • 3.51, пох. (?), 09:05, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    учитывая удивительный мирок ./debian/ и странности современного rpm (не умеющего без лишних пинков банально собрать все указанные ему файлы уже установленные куда и как надо в пакет) - checkinstall нельзя назвать плохим решением. Если бы еще и поддерживался...

     
  • 2.15, Аноним (34), 12:41, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это тебе они всем угодили. А нам не угодили libtoolize && autoconf && automake. Много сивухи.
     
  • 2.17, nobody (??), 12:44, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Лишних зависимостей маловато. Вот притянуть питон/руби/.NET/JRE/node.js/прочую-пoебень - наш выбор!
     
     
  • 3.20, Аноним (-), 12:53, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    уж лучше в завиимостях иметь питон, чем дич вроде autoconf
     
     
  • 4.21, nobody (??), 12:59, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей, и в этом его killer-фича.

    А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нужен - gmake+sh вполне хватает

     
     
  • 5.29, пох. (?), 17:06, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
    >  и в этом его killer-фича.

    причем - даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.
    Пересобирать configure ему ради этого не потребуется.

    Но манки-кодерков уже не остановить :-(


    > А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нужен

    autoconf обычно нужен из-за неумения написать какой-нибудь build.sh (и можно даже обозвать его configure, как, к примеру, nginx) обрабатывающий --with-another-ненужнаяхня.

    Ну не владеют обезьянки шеллом, не говоря уже про make, они только игого умеют.

     
     
  • 6.33, Аноним (34), 18:31, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.

    Даже если потребитель и не правит ничего в исходниках, а просто хочет их собрать неканоническим образом, например, со статическими либами… А там libtool… И всё, приплыли, configure падает.

     
     
  • 7.35, пох. (?), 18:38, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    у него все еще есть выбор - пропатчить достаточно простое место в сгенеренном makefile, или идти изучать дурацкий синтаксис.

    в случае мезона выбора нет - даже если ты всего лишь хочешь собрать бинарник - хромую хрень тебе в src.

    P.S. в целом же согласен - в отличие от самого autoconf, libtool - вредная и ненужная диверсия, не решившая никогда ни одной проблемы, для которых якобы была придумана, зато очень сильно изгадившая возможность ручного вмешательства в сборку.

     
     
  • 8.44, Аноним (34), 23:14, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так он не сгенерировался, configure же упал Чем он поможет libtool ломает логи... текст свёрнут, показать
     
     
  • 9.49, пох. (?), 08:59, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в смысле упал Вообще не нашел библиотеку в нестандартном месте На самом дел... текст свёрнут, показать
     
     
  • 10.52, Аноним (34), 10:12, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле, он и не знал, что её надо искать Они ищет libfoo, есть только libfoo ... текст свёрнут, показать
     
     
  • 11.65, souryogurt (ok), 13:34, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так если есть только libfoo a , libtool тут не причем Может собирете уже тогда... текст свёрнут, показать
     
     
  • 12.69, Аноним (34), 18:01, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз для тугодумов libfoo la тоже есть, но тест линковки стандартный автоко... текст свёрнут, показать
     
  • 7.47, souryogurt (ok), 02:51, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А можно подробнее, как именно configure падает? Сам libtool не нужен для дистрибутива с исходным кодом.
     
     
  • 8.53, Аноним (34), 10:16, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    См 52 Да что ты говоришь А если посмотреть повнимательнее и обнаружить волше... текст свёрнут, показать
     
     
  • 9.61, Аноним (34), 11:23, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотя нет, гоню Это было бы слишком просто для автодряни Скриптик libtool, ко... текст свёрнут, показать
     
     
  • 10.64, souryogurt (ok), 13:21, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И опа Для сборки из исходного кода, уже не нужен весь пакет libtool, а только s... текст свёрнут, показать
     
     
  • 11.70, Аноним (34), 18:04, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты читал, что я выше писал-то Не в том смысле ломает, что не следует политике н... текст свёрнут, показать
     
  • 5.48, Andrey Mitrofanov_N0 (??), 08:37, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    #>> чем дич вроде autoconf
    > Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
    > и в этом его killer-фича.

    Тише, тише!

    Это же Разработчик.  Да, он не умеет в автоконф, либтул, баш, си, сед, авк, ... всё вот это вот.

    Такие нонеча разработчики.  Субж во все поля...

     
     
  • 6.57, Клыкастый (ok), 10:33, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ретроград! Прогресс не остановишь!
     
     
  • 7.60, Andrey Mitrofanov_N0 (??), 11:23, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ретроград! Прогресс не остановишь!

    Ну, что вы!  Кто я такой, чтобы Ваш "прогресс" останавливать.

    Вы и сами отлично справляетесь.

    CMake, електрон, мейзон  --  выкидывайте и переписывайте уже.
       К нашим-то, к ретроградам, не примазывайтексь.
          Дальнейших успешных сингулярностей Вам.

     
  • 2.46, Анонм (?), 02:50, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    1. Пока не придется разбирать эти портянки, которые трассируются очень плохо. За Meson не скажу, но с CMake проблемы решаются намного проще.
    2. Язык оболочки ламповый, родной, но для чего-то кроме однострочников в интерактивном и эквивалентных им коротких скриптов он катастрофически ужасен.
    3. make штука не самая быстрая
    4. Checkinstall мертв, к сожалению. Но и когда был жив, часто проблем добавлял прилично (во всяком случае на не самых мейнстримных архитектурах)
     

  • 1.25, Ivan_83 (ok), 14:51, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживают

    Сомнительно, ИМХО может чтонить сломать

     
     
  • 2.45, Аноним (34), 23:16, 17/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Что и как это может сломать? Я так понял, изменилось только то, как флаги хранятся в кеше, а компилятор в конечном итоге получит все те же самые.
     
     
  • 3.66, Ivan_83 (ok), 15:17, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.
     
     
  • 4.72, Аноним (34), 23:11, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.

    Они всегда разные. И передаются компилятору именно что одной кучей. Как их при этом хранить — по отдельности или в месте — значения не имеет.
    Дай угадаю: ты просто не знаешь, что такое CPPFLAGS?

     

  • 1.38, Аноним (38), 20:08, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >systemd, GStreamer, Wayland, GNOME и GTK+.

    Не нужно.

     
  • 1.42, Аноним (42), 21:18, 17/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А уметь правильно писать Makefile похоже слабо юным хипстерам.
     
     
  • 2.50, пох. (?), 09:02, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "это ж мне что - все исходники ВРУЧНУЮ перечислять в зависимостях?"
    Не-не-не, вот прокатывающийся по ним скрипт, подбирающий весь мусор (включая пяток файлов, давно неиспользуемых) - это по нашему!

     
     
  • 3.54, Аноним (34), 10:25, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > "это ж мне что - все исходники ВРУЧНУЮ перечислять в зависимостях?"

    И ты, я гляжу, не осилил?
    https://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites

     
     
  • 4.63, нах_ (?), 13:01, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.

    make dep - там осиливать нечего (бонусом - что он обычно тоже нужен только один раз, при внесении изменений в дерево проекта, а не мелком патчинге) но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.
    А этих .cxx в крупном проекте может быть с миллиончик.

     
     
  • 5.68, Аноним (34), 17:59, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.

    И что же там gmake only? Шаблонные правила, разве что? Замени их суффиксными. Что ещё?

    > но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.

    А кто соберёт-то? automake не соберёт, cmake не соберёт, насчёт сабжа тоже сильно сомневаюсь.

     
  • 3.55, Аноним (55), 10:30, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давно было, написал универсальный makefile со всеми зависимостями, сам все находит строит зависимости, собирает. Не зависит ни от каких доп скриптов. Вообще делать с ним ничего не надо. Работает на любой системе, пихаю его везде. Таких лисапетов в инете давно полно. Нет, надо изобрести корявого глючного монстра.
     
     
  • 4.58, Аноним (34), 10:37, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Увы, такое реально только для hello world'ов. А если в проекте несколько библиотек и несколько бинарей, и у всего свои внешние зависимости, придётся таки чуть-чуть поднапрячься.
     
     
  • 5.59, Аноним (55), 10:49, 18/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    есть и список внешних либ и свои промежуточные и цели сколько надо, достаточно просто. А проекты далеко не самые простые.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру