The OpenNET Project / Index page

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

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

11.03.2019 09:14

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

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


   project('tutorial', 'c')
   executable('demo', 'main.c')

или более сложный вариант с зависимостью от GTK3:

   project('tutorial', 'c')
   gtkdep = dependency('gtk+-3.0')
   executable('demo', 'main.c', dependencies : gtkdep)

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

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

  • Добавлена поддержка развиваемых компанией NVIDIA компиляторов PGI для языков C, C++ и Fortran, а также компилятора Flang;
  • Добавлена поддержка расширения coarray для параллельного программирования на языке Fortran, стандартизированного в спецификациях Fortran 2008 и Fortran 2018. В коде для разбора зависимостей также представлена начальная поддержка субмодулей для Fortran, определяемых при помощи выражения "submodule";
  • Обеспечена возможность указания пути к каталогу с модулями для системы CMake в составе зависимостей. Бэкенд для определения зависимостей через CMake теперь может использовать существующие файлы Find{name}.cmake через указание свойства make_module_path в dependency(). Также добавлена поддержка передачи CMake дополнительных параметров при помощи опции cmake_args;
  • Значение libdir при кросс-компиляции теперь указывает на каталог "/lib", а не на специфичные для выбранной архитектуры пути (например "lib/x86_64-linux-gnu");
  • В сборочные файлы добавлена новая секция "[paths]" для определения постоянных путей, таких как prefix и libdir;
  • Добавлен режим "warning_level 0" для отключения в компиляторе любых проверок, связанных со статическим анализом кода;
  • Добавлена встроенная сборочная цель (ninja clang-format) для форматирования кода при помощи clang-format;
  • Реализована возможность указания в ключевом слове include_directories строковых значений, а не только объектов, ссылающихся на каталоги;
  • Для языков C, C++ и Fortran добавлена поддержка обработчиков формата для обмена научными данными NetCDF через вызов pkg-config;
  • Добавлена поддержка формата HDF5 через вызов pkg-config;
  • Добавлена поддержка компиляции кода NVIDIA CUDA (пока только при помощи бэкенда на базе Ninja). Так как компилятор CUDA не сохраняет файлы с зависимостями (*.d), отслеживание зависимостей не поддерживается;
  • Расширены возможности интроспекции. Обеспечена генерация файла meson-info.json при каждом запуске meson. Добавлена поддержка инроспектирования разом нескольких параметров. Реализована возможность выполнения "introspect --targets" и "introspect --buildoptions" без настроенного сборочного каталога. Добавлена команда "introspect --scan-dependencies" для поиска зависимостей в проекте;
  • Добавлена функциональность для изменения файлов meson.build при выполнении операций в командной строке. Например, можно добавлять и исключать исходные файлы и сборочные цели (target), изменять наборы kwargs и модифицировать применяемые по умолчанию сборочные опции.


  1. Главная ссылка к новости (https://groups.google.com/foru...)
  2. OpenNews: Выпуск сборочной системы Meson 0.49.0
  3. OpenNews: Доступна система сборки Meson 0.42, на которую переходят systemd, GTK+ и GNOME
  4. OpenNews: Первый публичный выпуск сборочного инструментария build2
  5. OpenNews: Разработчик языка XL опубликовал новую сборочную систему build
  6. OpenNews: Проект Qt прекращает разработку сборочной системы Qbs в пользу CMake
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50288-meson
Ключевые слова: meson, build, make
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:35, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему недостаточно обычного make?
     
     
  • 2.2, llolik (ok), 10:41, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На официальном сайте написано, вроде как.
    http://mesonbuild.com/FAQ.html#why-is-there-not-a-make-backend

    Вкратце: шустрей и проще.

     
     
  • 3.6, shjfbg (?), 11:06, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    ребята неосилили cmake + ninja
    потому и пишут гупые отмазки типа:
    What is the correct way to use threads (such as pthreads)?

    thread_dep = dependency('threads')

    This will set up everything on your behalf. People coming from Autotools or CMake want to do this by looking for libpthread.so manually. Don't do that, it has tricky corner cases especially when cross compiling.

    а делов-то:
    https://stackoverflow.com/questions/33991918/link-to-pthread-library-using-cma

    set(THREADS_PREFER_PTHREAD_FLAG ON)
    find_package(Threads REQUIRED)
    target_link_libraries(my_app threads::Threads)

     
     
  • 4.7, llolik (ok), 11:23, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В чём отмазка? Я понял это как памятку : не надо искать libpthread.so вручную (впрочем, если очень хочется ходить по граблям, то принципиально не запрещается). Вроде больше тезисов в тексте не наблюдается.
     
     
  • 5.19, shjfbg (?), 12:24, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >People coming from Autotools or CMake want to do this by looking for libpthread.so manually.

    Это неверно, cmake умеет сам находить нужный dev-пакет и подключать зависимости (заголовки, библиотеки). Ничего руками делать не надо (можно, но не надо).

     
     
  • 6.22, llolik (ok), 12:45, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>People coming from Autotools or CMake want to do this by looking for libpthread.so manually.
    > Это неверно, cmake умеет сам находить нужный dev-пакет и подключать зависимости (заголовки,
    > библиотеки). Ничего руками делать не надо (можно, но не надо).

    Ну напишите им на github (или сразу патчем, там github markdown), как надо. Наверное, можно даже с примером CMake. Исправят.

     
  • 3.8, Аноним (8), 11:25, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Прочитал статью Чувак написал с нуля свою замену make и ускорил сборку Хрома с ... большой текст свёрнут, показать
     
     
  • 4.12, llolik (ok), 11:31, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Просто за отправку патчей в GNU Гугл бы ему премиальные не заплатил.

    И ещё далеко не факт, что эти патчи приняли бы. Мало того, что там, мягко говоря, очень консервативные люди и не любят резких изменений, так и, насколько я в курсе, он значительную часть "наворотов" из make повыкидывал, оставив только то, что жизненно важно для сборки.

     
  • 4.14, Ordu (ok), 11:34, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне кажется, если бы сами разработчики make переписали его с нуля в расчёте на масштабы современных проектов, там был бы выигрыш больше 4 секунд.

    Но они ведь не переписали.

    > "For fun" это конечно мощная мотивация, но по-моему он лукавит, — в отличии от Торвальдса он своим детищем занимался не в свободное от учёбы время, а за гугловскую зарплату и в расчёте на печально известные гугловские премиальные для стимуляции NIH-разработок. Просто за отправку патчей в GNU Гугл бы ему премиальные не заплатил.

    Ну, конечно, за всем стоит вселенский заговор. Даже если бы ему гугл заплатил за правку make столько же, сколько за создание альтернативы make, он скорее всего создал бы альтернативу. Это проще. Гораздо проще. Сделай info make в консольке, полистай документацию. И задумайся о том, как можно не сломав ничего, что-то исправить. На практике это выльется в огромные усилия инвестированные в изучение существующего кода, поисков каких-нибудь хитрозавёрнутых дыр, как можно оптимизировать что-то, не поломав ничего другого, или поломав минимум, а потом в длинные споры с gnu о том, как надо что-либо менять. И эти длинные споры могут оказаться самой гнусной вещью. Могут не оказаться, но ты не узнаешь, пока не инвестируешь кучу времени в изучение make. Кстати есть ещё такой чувак как Столлман, который иногда совершенно непредсказуемо вмешивается и накладывает своё вето. Бррр. Связываться с этим? Да ну его нафиг.

     
     
  • 5.20, Аноним (20), 12:27, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Есть мнение, что Ninja писали из-за винды. Make там хронически медленный из-за порождения тучи процессов, что на винде затратно.
     
  • 5.23, Аноним (8), 12:51, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А мне-то что с этого Что Гугл, что GNU, 8212 чёрные дыры, обслуживаемые робо... большой текст свёрнут, показать
     
     
  • 6.26, Аноним (26), 13:55, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В ninja особо MAKEFLAGS и не нужны. Эта система не предполагает ручного создания файлов для нее. Все файлы должны генерироваться какой-то внешней, более высокоуровневой тулзой. И именно в этой тулзе и нужно задавать все параметры для ninja. Хочешь что-то поменять - перегенерируй файлы.
     
  • 6.27, Ordu (ok), 14:02, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А мне-то что с этого?

    А мне? Или разработчику ninja? Ты сейчас смотришь с позиции, мол, разработчик ninja ничем не лучше разработчиков gnu. Но какое мне до этого дело? На самом деле, это даже хорошо. Больше поводов у сочувствующих продолжать увеличивать разнообразие тулсета, запиливая всё больше и больше альтернатив. Конкуренция -- это хорошо. Монополия -- плохо.

    > Так что с моей точки зрения, проталкивание Ninja, Meson и прочего хипстерского
    > барахла ­— чистой воды вредительство. Их авторы ещё не успели ничего
    > толком сделать, а уже ничем не лучше своих предшественников, — в
    > том числе в плане архитектурной гибкости и лёгкости внесения изменений.

    Фишка в том, что мне плевать, что ты или кто-либо ещё думает о хипстерстве или вредительстве. Я буду использовать ту систему сборки, которая мне удобнее. И если мне удобнее ninja, я буду пользоваться ninja. На самом деле, время когда мне были интересные вещи типа make или ninja давно прошло, мне давным-давно надоело писать makefile'ы. Мне гораздо больше нравится, когда makefile'ы пишутся за меня системой сборки. И будут ли эти makefile'ы для ninja или для gnu make -- мне глубоко фиолетово.

     
  • 2.4, Аноним (4), 10:50, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А ты пробовал обычным make собирать что-то большое и кроссплатформенное? Причём именно _обычным_ make, без GNU-расширений.
     
     
  • 3.11, yet another anonymous (?), 11:30, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У нас практически не осталось _обычного_ make, без GNU-расширений.
     
     
  • 4.50, Аноним (50), 18:08, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Рад за _вас_.
     
  • 3.15, пох (?), 11:40, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А ты пробовал обычным make собирать что-то большое и кроссплатформенное?

    я пробовал - freebsd называется (ну, насколько обычен тамошний pmake или бывший до него bmake - отдельный вопрос). Большое, кроссплатформенное. Собирается, да.

    ну так ее программисты писали, настоящие, а не любители обмазаться модными фичами за день до их релиза.

    А вот сколько раз апгрейд линуксного ядра ломал ваш любимый gnu make - можете поискать, сравнив несколько десятков INSTALL из разных версий. (нет, я не знаю как так оно было написано, что ломается именно из-за ядра, а не из-за библиотек)

     
     
  • 4.48, Аноним (50), 18:00, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > насколько обычен тамошний pmake или бывший до него bmake - отдельный вопрос

    OMG, они теперь и bmake на что-то заменили? Вроде не так давно его по умолчанию сделали-то.
    И да, bmake ни разу не обычен, и, насколько я помню, в портах его специфика используется очень много где, потому что без неё на голом POSIX далеко не уедешь.

     
     
  • 5.51, пох (?), 18:10, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    пардон, bmake vs fmake - вечно я путаю эти буковки (поскольку один хрен никогда никто их так не зовет)

    ну, типа если где-то не апгрейдились со времен 8.4, боюсь, да, ждут сюрпризы при попытках собрать современные порты (впрочем, одним апгрейдом мэйка оно не решается).

    Но 8.x шесть лет назад кончилась, можно ж уже и пережить расставание.

    У fmake большая часть этих фокусов тоже в наличии, со времен как бы не 386BSD - можно уже и забить на единственно-верный позикс.

     
     
  • 6.54, Аноним (50), 21:20, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да круто, кроуто, что там есть эти фокусы. Проблема только в том, что они с фокусами gmake ни разу не совместимы, поэтому о переносимости Makefile'ов можно забыть.
     
     
  • 7.57, Аноним (50), 21:46, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    P. S. Действительно, make уже не торт:


    $ make love
    make: don't know how to make love. Stop


     

  • 1.3, Аноним (3), 10:48, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Требует python или jvm или какого-нибудь другого огромного рантайма на сотни мегабайт в распакованном виде === можно закапывать.
     
     
  • 2.5, мое правило (?), 11:03, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Требует ядро, операционную систему, другого сабжа в много мегабайт между железом и аппликухой - можно закапывать.
     
  • 2.10, llolik (ok), 11:27, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Никто не запрещает не пользоваться. У меня вот нет задачи не использовать Python, и фрустрации от него тоже нет - я пользуюсь, мне meson, не без огрехов, но нравится.
     
     
  • 3.13, пох (?), 11:33, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Никто не запрещает не пользоваться.

    угу, вы же предусмотрели возможность "медленной" и "сложной" сборки, например, с помощью банального gnu configure, или пред-упакованных готовых мэйкфайлов на худой конец, если мне нужно банально собрать ваш проект для своего использования, а не заниматься его разработкой?

    ах, нет, для вас это слишком сложно?

     
     
  • 4.16, llolik (ok), 11:52, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ах, нет, для вас это слишком сложно?

    Если конкретно обо мне речь, то Makefile писать вручную я ещё не разучился. Есть задача, напишу, нет задачи - зачем. Но в плане выбора между CMake и Meson лично я склонился в сторону Meson. Призывов всем переходить не делаю, пусть каждый смотрит сам, что лично ему надо.

    > банально собрать ваш проект для своего использования, а не заниматься его разработкой

    Вот мне порой банально тоже хочется заюзать библиотеку, и приходится переписывать сборку. libuv, например, перекатал https://github.com/SkyMaverick/UniChatMod/tree/master/deps/uv (проектик воскресный любительский; цель, чтобы сборка и deps-ы собирались штатными компиляторами платформы, т.е. gcc/clang и msvc без тонн переписывания сборки под платформы).

     
     
  • 5.17, пох (?), 12:09, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если конкретно обо мне речь, то Makefile писать вручную я ещё не разучился.

    хм, ну и как насчет быстренько вручную накатать мэйкфайлов к чему-то типа chromium ?

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

    одно дело - крошечная libuv, другое - что-то большое что ВНЕЗАПНО решило потоптать за твой счет нехоженных граблей, и внезапно вместо мэйкфайлов или их системонезависимого (!) генератора - приволокло зависимость от jvm. "ну ок, в крайнем случае xcode".

    впрочем, теперь еще и докер модно использовать для сборки, чтоб совсем мозг не напрягать. Причем подсунуть файл с FROM:ubuntu (без указания версии, то есть завтра оно к хренам сломается)

    так что да, надо учиться восстанавливать мэйкфайлы по артефактам помойко-систем типа мезона. :-( воистину задача для гуглового ИИ.

     
     
  • 6.21, llolik (ok), 12:38, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > хм, ну и как насчет быстренько вручную накатать мэйкфайлов к чему-то типа
    > chromium ?

    Автотулзы для проектов типа chromium кактус не сильно лучший.
    > их системонезависимого (!) генератора - приволокло зависимость от jvm

    Вот серьёзно, где сейчас нет python? Я понимаю, что специфических случаев наискать можно, но в массе своей, где. К тому же meson не нужно каких-то особенных модулей, достаточно core.

    > впрочем, теперь еще и докер модно использовать для сборки, чтоб совсем мозг
    > не напрягать. Причем подсунуть файл с FROM:ubuntu (без указания версии, то
    > есть завтра оно к хренам сломается)

    Если это про меня, то указание версии там стоит 14.04. И докер там не для сборки на пользовательской системе, а для travis-ci, у которого по дефолту ЕМНИП xenial(когда начинал с этим разбираться был precise от чего были траблы) и вообще, с ним (трэвисом) навытанцовывавшись, оказалось что проще сделать докер с минимальной убунтой, которую хочется поддерживать (т.е. trusty в моём случае)+зависимости и собирать так. В остальном докер не нужен. Я пишу и собираю на bionic (на mint19 если точней) без проблем.

    > так что да, надо учиться восстанавливать мэйкфайлы

    В этом есть какой-либо смысл?

     
     
  • 7.28, пох (?), 14:07, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Автотулзы для проектов типа chromium кактус не сильно лучший.

    почему? Это один из немногих действительно кроссплатформенных проектов (напоминаю, изначально автотулз для этого придумали, а не для альтернативно-одаренных-не-умеющих-мэйк), плюс собирающийся десятком разных вариантов.

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

    Поэтому соглашайтесь на cmake, пока жабу не потребовали ;-)

    >> так что да, надо учиться восстанавливать мэйкфайлы
    > В этом есть какой-либо смысл?

    ну, я бы дорого заплатил за такую штуку, которая  позволяла бы запускать ее один раз где-то (где уже не важно что она потребует кластер для своего ИИ и весь интернет впридачу ;-) и получить набор мэйкфайлов, на которые можно просто натравить make на целевой системе, без уставновки там питона шести разных веток, go, jvm и докера. Можно даже без аналога configure (это по нынешним меркам вообще невозможная магия - ничего кроме sh не используя, получить переносимую кроссплатформенную собиралку без внешних зависимостей), только под одну платформу и один конфиг.

    > Если это про меня

    нет, я даже не заметил что там тоже докер ;-) просто уже очень часто натыкаюсь. Ладно убунта, а то ж может быть какая-нибудь федора, каждый месяц новая. Ну не успел автор об этом узнать - он через шесть месяцев уже забыл об этом проекте.

     
     
  • 8.33, llolik (ok), 15:08, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    для действительно крупных проектов - время пересборки Для небольших проектов - ... текст свёрнут, показать
     
  • 8.46, Ivan_83 (ok), 17:25, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    автотулс ужасен, смейк вполне юзабелен В принципе месон тоже весьма, но мне отк... текст свёрнут, показать
     
  • 7.43, пох (?), 17:15, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вот серьёзно, где сейчас нет python?

    вот, специально проверил - ни на одной моей фре, кроме тех куда его притащил hg - нету.
    hg на моих системах, если что - всё, потому что терпеть ради него еще и хипста-хруст я не собираюсь, а разработчики, увы, упрлсь.

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

    > К тому же meson не нужно каких-то особенных модулей, достаточно core.

    который из пяти? ;-)

     
  • 2.36, metakeks (?), 15:32, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сцать им, им дядька компы и облака покупает, сами туда ни копейки не вкладывают
     
  • 2.59, Анонас (?), 10:11, 12/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ===

    Судя по выражениям, тебе нужна система сборки на Node.JS

     

  • 1.9, yet another anonymous (?), 11:26, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Сборка "xcode и VisualStudio" ооочень актульна для X сервера.
     
  • 1.24, Совершенно другой аноним (?), 13:44, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не совсем понятно, зачем в системе сборки знать компиляторы? make как-то обходился без этого сакрального знания. Ему вообще было абсолютно всё-равно что собирать, хоть исполняемый файл, а хоть и книгу.

    Особенно непонятно зачем ему знать диалекты языка fortran, он что, ещё и сам эти файлы анализирует? и как с новым компилятором, ему нужна явная поддержка всех языков?

     
     
  • 2.31, llolik (ok), 14:24, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не совсем понятно, зачем в системе сборки знать компиляторы?

    Система сборки в общем-то изначально и должна запускать компиляторы. Как она будет запускать какой-нибудь rustс (с какими ключами, какие тесты компилятора, как его звать и где искать в конце концов) если она о нём ничего не знает?
    > make как-то обходился без этого сакрального знания. Ему вообще было абсолютно всё-равно что собирать, хоть исполняемый файл, а хоть и книгу

    meson - это не альтернатива make, meson - это альтернатива autotools.

     
     
  • 3.32, Led (ok), 14:57, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > meson - это альтернатива autotools.

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

     
     
  • 4.34, llolik (ok), 15:17, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Питоноподелие может казаться алтернативой чему-либо только для "альтернативных".

    Как мне назвать, чтобы не обидеть, человека, который считает, что его частное, ничем не подтверждённое мнение единственно и безальтернативно верное?

     
     
  • 5.52, пох (?), 18:11, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Led ;-)
     
  • 5.58, Led (ok), 23:09, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Питоноподелие может казаться алтернативой чему-либо только для "альтернативных".
    > Как мне назвать, чтобы не обидеть, человека, который считает, что его частное,
    > ничем не подтверждённое мнение единственно и безальтернативно верное?

    Как хош.

    Что касается моего мнения, то оно не верное (для тебя) - ты можешь (и должен) продолжать кодить на питоне - иначе это будешь уже не ты.

     
     
  • 6.63, Анончег (?), 23:46, 12/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что касается моего мнения, то оно не верное (для тебя) - ты
    > можешь (и должен) продолжать кодить на питоне - иначе это будешь
    > уже не ты.

    Светодиод практически развивает в своих отложениях альтернативную орфографию - даёшь - больше - дефисов - иначе это - будешь - уже - не - ты.

    Как всегда гениально. За это изобретение - плюсанул - Светодиода - прямо - в - карму.

     
  • 3.35, Совершенно другой аноним (?), 15:18, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> make как-то обходился без этого сакрального знания. Ему вообще было абсолютно всё-равно что собирать, хоть исполняемый файл, а хоть и книгу
    > meson - это не альтернатива make, meson - это альтернатива autotools.

    спасибо за объяснение. К сожалению не являюсь знатоком autotools, так-что не могу знать, может старшие товарищи подскажут - тот тоже знал версии стандартов fortran-а и прочих языков? на пользовательском уровне я помню, что он позволял проверить наличие библиотек/конкретных функций, но в стандарты не лез, по причине вышесказанного могу ошибаться.

     
     
  • 4.38, llolik (ok), 16:00, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > он позволял проверить наличие библиотек/конкретных функций, но в стандарты не лез, по причине вышесказанного могу ошибаться.

    https://www.opennet.ru/docs/RUS/autoconf/autoconf-ru_4.html
    смотреть Macro: AC_PROG_F77 . Там описано как определяется компилятор и выставляются ключи.

     
     
  • 5.40, Совершенно другой аноним (?), 16:03, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> он позволял проверить наличие библиотек/конкретных функций, но в стандарты не лез, по причине вышесказанного могу ошибаться.
    > https://www.opennet.ru/docs/RUS/autoconf/autoconf-ru_4.html
    > смотреть Macro: AC_PROG_F77 . Там описано как определяется компилятор и выставляются ключи.

    Спасибо

     
  • 5.41, Совершенно другой аноним (?), 16:13, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> он позволял проверить наличие библиотек/конкретных функций, но в стандарты не лез, по причине вышесказанного могу ошибаться.
    > https://www.opennet.ru/docs/RUS/autoconf/autoconf-ru_4.html
    > смотреть Macro: AC_PROG_F77 . Там описано как определяется компилятор и выставляются ключи.

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

     
     
  • 6.42, llolik (ok), 16:46, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/fort

    Вот модуль поддержки фортрана. С 288 макрос AC_PROG_FC.
    Принципиально да, для каждого компилятора определяется своя коммандная строка.

     
     
  • 7.47, Совершенно другой аноним (?), 17:44, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/fort
    > Вот модуль поддержки фортрана. С 288 макрос AC_PROG_FC.
    > Принципиально да, для каждого компилятора определяется своя коммандная строка.

    Спасибо за подсказку. Таки версии стандартов есть. Правда как я понял, он его не сам определяет, а ожидает что ему скажет пользователь. Возможно meson делает так-же, тогда вопросов по этому поводу нет. Ещё раз спасибо, за разъяснение.

     
  • 3.45, пох (?), 17:22, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    весь прикол, как-то не замеченный авторами-улучшателями мира, в том, что autotools на конечной системе для сборки (даже для сборки вручную модифицированного кода и не в той единственно-верной конфигурации) совершенно не требовались, если только специально не сделать какой-нибудь вредной фигни.

    Возможность конфигурирования - оставалась.

     
     
  • 4.55, Аноним (50), 21:26, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    autotools, которому «ничего не требуется», пихает в исходники столько своих супер-пупер-переносимых скриптов, что проще было бы таскать с собой сабж вместе с исходниками питона, который собирать прямо во время конфигурации. Не исключено, что это даже быстрее вышло бы.
     
     
  • 5.60, пох (?), 19:07, 12/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > autotools, которому «ничего не требуется», пихает в исходники столько своих
    > супер-пупер-переносимых скриптов

    сколько? Целых четыре, в крайнем случае?

    > что проще было бы таскать с собой сабж вместе с исходниками питона

    мастер гипербол, ага.

    впрочем, пример мурзилы показывает, что ниасиляторы могут ухитриться даже засунуть таки питон поверх автоконфа (неосиляторы они ж неосиляторы везде, разобрать чужое и собрать заново теми тулзами, которые они кое-как осилили - для них тоже неосиливаемая задача)

    но быстрее почему-то не вышло.

     
  • 2.49, Аноним (50), 18:06, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Не совсем понятно, зачем в системе сборки знать компиляторы?

    Ну а как ты скажешь неизвестному компилятору, чтобы он использовал определённый стандарт языка, например? У каждого свои опции, только самые базовые (типа -I, -D, -o, -c) более или менее универсальны.

     
     
  • 3.53, пох (?), 18:13, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а твоя программа, ну конечно же, немедля и соберется "неизвестным компилятором", в особенности вот, конечно же, фортрана.

    > У каждого свои опции, только самые базовые (типа -I, -D, -o, -c) более или менее универсальны.

    и если твоей программе этого недостаточно - вероятнее всего, она не соберется вообще ничем, кроме единственно-верного gcc10deep-pre-alpha на твоем личном ящике.

    Чего ж тогда и беспокоиться?

     
     
  • 4.56, Аноним (50), 21:27, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зато ты можешь не беспокоиться, что твоя программа не соберётся, правильно?
     
     
  • 5.61, пох (?), 19:11, 12/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну если вы владеете автоконфом, это не проблема - учитесь у авторов mono, которые сперва требовали миллион переменных окружения выставить, потом запустить автоконф каким-то особенно кривым образом, кажется, стоя в корне но не из корневого каталога, или  наоборот - а потом плевали в тебя полный скрин текста примерно такого содержания: "мы поддерживаем линукс, линукс, и примерно нихрена, а тут что-то другое, поэтому пойдите вон туда, создайте там каталог uname рядом с имеющимися, и напишите в него сотню мегабайт кода, который мы не умеем писать платформонезависимо, образцы рядом, документацию нам писать лень" и вываливались с ошибкой.

    без autoconf'а - вот как бы они это могли бы проделать?

     

  • 1.25, Аноним (25), 13:46, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    как получить версию проекта из meson.build?
     
     
  • 2.29, альтернативный разработчик (?), 14:09, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а вам зачем? Мы все равно поддерживаем только самую распоследнюю.

    git pull, чего там думать, трясите!

     
     
  • 3.44, Аноним (25), 17:19, 11/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Номер версии проекта, конкретно мне, нужен для сборочных скриптов.
    Не во всех проектах указывается версия в tag или в логах может быть просто bumped version без циферок или модулей и сабпроджектов есть meson.build со своей версией.
     

  • 1.37, Аноним (37), 15:52, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пытался использовать meson под Widnows. Очень тяжело идет.
    В основном ревью кода meson и написание meson.build под платформу.
    Поддержка всяких библиотек очень плохая. Кто работает с meson и будет портировать предложите автору использовать хотя бы conan как модульную систему.
     
  • 1.39, DmA (??), 16:00, 11/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Что мы аля Микрософт что-ли, чтобы очевидным словом называть программу(почтовую -Mail,  браузер -Internet Explorer) make, пусть будет Мезоном или Глююоном.
    Это как номера машин у бандитов, памяти у них нет, поэтому покупают номера с одинаковыми цифрами и буквами, запомнить не могут.
     
  • 1.62, Аноним (62), 21:54, 12/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Система, возникшая 42 года назад. 42...

    В треде есть на тему: не хватает функциональности (применено слово фокус).

    Ну, да, временами жаль, что из прогресса есть ещё что заимплементить.

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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