From: Mikhail Novosyolov <mikhailnov@altlinux.org> To: devel@lists.altlinux.org Subject: Re: [devel] I: cmake macros Date: Wed, 16 Jun 2021 22:00:54 +0300 Message-ID: <ee869bad-a980-ae8f-22d3-4e213b67e552@rosalinux.ru> (raw) In-Reply-To: <YMjwiJlWlpXsyp9k@cello> 15.06.2021 21:26, Arseny Maslennikov пишет: > On Tue, Jun 15, 2021 at 08:26:29PM +0300, Mikhail Novosyolov wrote: >> А в чем цель отказа от Unix Makefiles и перехода на cmake --build? > cmake сама не собирает и не инсталлирует артефакты, а генерирует файлы для > некоторого исполнителя сборочных правил (бекенда, см. > cmake-generators(7)). Команда «cmake --build $builddir» не зависит от > используемого бекенда, поэтому её можно использовать с любыми бекендами. > > Никакого «отказа от Unix Makefiles» я не предлагаю, несмотря на > тот факт, что make(1) на роль исполнителя генератных сборочных правил > годится так себе по ряду причин[*]. Но, если пакет по той или иной > причине зависит от некоторого конкретного генератора правил, лучше его > явно в спеке передать с -G. Здесь более интересен вопрос - а чем Unix Makefiles плохи в масштабах дистрибутива. Я как-то задавался таким вопросом, глубоко тему не изучал, но сходу ничего толкового не придумал. Makefile-ы понятны, предсказуемы, их можно грязно похакать при необходимости, чего не скажешь о cmake в целом. Случаев, когда они бы не справлялись со сборкой пакета, не встречал. Подозреваю, что большое разнообразие вариантов запуска cmake в спеках Альта следствие не того, что стандартные макросы плохи и не подходят для конкретного случая, а следствие слабости их документирования, трудности поиска примеров, желания изобрести велосипед. Или я не прав? > >> В таблице по ссылке на вики приведено " %makeinstall_std -C BUILD" в качестве рекомендуемого макроса.Вы хотите отказаться отпривязки к BUILD и тут же предлагаете прямо в спек ее прописывать? > В таблице в левом столбце описаны разные выражения в старых макросах, > которые встречаются (или встречались) в спеках, и аналогичные выражения > в новых. Она предназначена для случая, если кому-то неохота или некогда > прочесть файл с макросами[1], но хочется понять, что изменилось. > >> Рассматривался ли вариант cmake --install? > Сейчас %cmake_install именно в эту команду и раскрывается и > рекомендуется для типичных случаев. Предыдущий %cmake_install был просто > бесполезен. > >> В общем , прочитав тред, не понял, зачем эти изменения. В audacity.spec [1] сейчас так: >> >> %cmake \ >> -Daudacity_lib_preference:STRING=system \ >> -Daudacity_use_ffmpeg:STRING=linked \ >> -Daudacity_use_lame:STRING=system \ >> -Daudacity_use_libflac:STRING=system \ >> -Daudacity_use_libid3tag:STRING=system \ >> -Daudacity_use_libsndfile:STRING=system \ >> -Daudacity_use_libsoxr:STRING=system \ >> -Daudacity_use_libtwolame:STRING=system \ >> -Daudacity_use_libvamp:STRING=system \ >> -Daudacity_use_libvorbis:STRING=system \ >> -Daudacity_use_libv2:STRING=system \ >> -Daudacity_use_sbsms:STRING=system \ >> -Daudacity_use_soundtouch:STRING=system \ >> -Daudacity_use_portaudio:STRING=local \ >> -Daudacity_use_midi:STRING=local \ >> -DAUDACITY_SUFFIX:STRING="" >> >> %cmake_build >> >> %install >> %cmakeinstall_std >> >> Нужно ли здесь что-то менять? > Разве что %cmakeinstall_std на %cmake_install. Спасибо. > > В целом, здесь достаточно тривиальный случай, поэтому и адаптировать > ничего не пришлось. > > Изначально я задумывался о том, чтобы убрать %cmakeinstall_std вообще, > но очень много спеков сизифа его используют, а часть из них не сломались > после task 269879, как audacity. Поэтому (только после того, как в p9 > пройдёт задание 272559) планируется снабдить его %warning-ом и > пояснительной надписью и потихоньку вытеснять. Макросов %make* столько, что, с учетом знания их вариаций в других дистрибутивах, в них очень легко запутаться, теперь и здесь стопицот вариантов... Но без этого не перейти на новые, более логичные и соответствующие современному функционалу cmake, макросы. %cmake, %cmake_build и %cmake_install выглядят логично и аналогичны %meson, %meson_build и %meson_install, а также %make, %make_build, %make_install , только вот в %make_install DESTDIR не задается. > > [1] http://git.altlinux.org/people/arseny/packages/cmake.git?p=cmake.git;a=blob;f=.gear/cmake.macros;h=e9bc3f055dc25457d2072748e5b7dc5e5b7db812;hb=33e1f9d741a2439266bb2e72c5a763b58ae112f4 > [*] JT: Вообще, если адаптировать Unix Haters' handbook к современности, > то make(1) будет главным уродом в программе цирка. Уж лучше автокрап и мейкфайлы и даже meson, чем cmake. ИМХО. Очень не люблю его. Документация непонятная. И, интересно, как разруливается кольцевая сборочная зависимость cmake<->libuv при бутстрапе на новые архитектуры.
next prev parent reply other threads:[~2021-06-16 19:00 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-31 9:20 Arseny Maslennikov 2021-05-31 10:09 ` Andrey Cherepanov 2021-05-31 10:22 ` Grigory Ustinov 2021-05-31 10:38 ` Andrey Cherepanov 2021-05-31 10:50 ` Arseny Maslennikov 2021-05-31 11:06 ` Andrey Cherepanov 2021-05-31 11:53 ` [devel] noarch check failed Dmitry V. Levin 2021-05-31 14:26 ` Vladimir D. Seleznev 2021-05-31 14:28 ` Dmitry V. Levin 2021-05-31 14:32 ` Vladimir D. Seleznev 2021-05-31 14:55 ` Dmitry V. Levin 2021-05-31 17:03 ` Andrey Savchenko 2021-05-31 17:36 ` Vladimir D. Seleznev 2021-05-31 14:30 ` Arseny Maslennikov 2021-05-31 15:06 ` Arseny Maslennikov 2021-05-31 15:52 ` Yuri Sedunov 2021-06-01 9:16 ` Yuri Sedunov 2021-05-31 10:45 ` [devel] I: cmake macros Arseny Maslennikov 2021-05-31 13:49 ` Aleksei Nikiforov 2021-05-31 14:06 ` [devel] noarch check failing Arseny Maslennikov 2021-05-31 16:33 ` [devel] I: cmake macros Arseny Maslennikov 2021-06-01 7:44 ` Aleksei Nikiforov 2021-05-31 10:39 ` Dmitry V. Levin 2021-05-31 10:46 ` Arseny Maslennikov 2021-05-31 12:02 ` Anton Farygin 2021-05-31 12:09 ` Sergey V Turchin 2021-05-31 12:13 ` Anton Farygin 2021-05-31 12:53 ` Arseny Maslennikov 2021-05-31 12:58 ` Sergey V Turchin 2021-05-31 13:02 ` Sergey V Turchin 2021-05-31 14:22 ` Arseny Maslennikov 2021-05-31 15:00 ` Anton Farygin 2021-05-31 15:04 ` Sergey V Turchin 2021-05-31 15:19 ` Anton Farygin 2021-06-02 7:58 ` Sergey V Turchin 2021-05-31 15:01 ` Sergey V Turchin 2021-05-31 13:06 ` Sergey V Turchin 2021-05-31 13:09 ` Sergey V Turchin 2021-05-31 13:11 ` Sergey V Turchin 2021-05-31 13:17 ` Sergey V Turchin 2021-05-31 13:28 ` Andrey Savchenko 2021-05-31 13:52 ` Arseny Maslennikov 2021-05-31 14:28 ` Arseny Maslennikov 2021-05-31 14:39 ` Andrey Savchenko 2021-05-31 14:52 ` [devel] циферки (was: I: cmake macros) Arseny Maslennikov 2021-05-31 14:57 ` Andrey Savchenko 2021-05-31 15:10 ` Arseny Maslennikov 2021-05-31 15:18 ` Andrey Savchenko 2021-05-31 18:07 ` [devel] I: cmake macros Arseny Maslennikov 2021-06-02 7:56 ` Sergey V Turchin 2021-06-15 17:40 ` Mikhail Novosyolov 2021-05-31 15:01 ` Andrey Savchenko 2021-05-31 15:29 ` Arseny Maslennikov 2021-05-31 15:38 ` Anton Farygin 2021-05-31 15:43 ` Grigory Ustinov 2021-05-31 17:40 ` Andrey Savchenko 2021-05-31 15:51 ` Andrey Savchenko 2021-05-31 16:15 ` Arseny Maslennikov 2021-05-31 17:11 ` Andrey Savchenko 2021-06-02 8:02 ` Sergey V Turchin 2021-06-04 8:49 ` Sergey V Turchin 2021-06-15 12:20 ` Sergey Afonin 2021-06-15 18:26 ` Arseny Maslennikov 2021-06-16 19:00 ` Mikhail Novosyolov [this message] 2021-06-16 20:31 ` Vladislav Zavjalov 2021-06-22 5:24 ` Michael Shigorin 2021-06-22 8:51 ` Arseny Maslennikov 2021-06-23 10:55 ` Sergey Afonin 2021-06-23 11:21 ` Arseny Maslennikov 2021-07-07 10:37 ` Nikolai Kostrigin 2021-07-07 11:35 ` [devel] MySQL в p9 (was: I: cmake macros) Arseny Maslennikov 2021-07-07 12:17 ` Nikolai Kostrigin 2021-07-07 16:18 ` [devel] I: cmake macros Arseny Maslennikov 2021-07-08 11:34 ` Nikolai Kostrigin 2021-06-25 14:30 ` [devel] I: cmake macros already in p9 Arseny Maslennikov 2021-07-06 6:22 ` Sergey Afonin 2021-07-06 9:31 ` [devel] MySQL + mysql-workbench-community в p9 (was Re: I: cmake macros already in p9) Nikolai Kostrigin 2021-07-06 9:51 ` Nikolai Kostrigin 2021-07-06 12:43 ` Nikolai Kostrigin 2021-07-06 15:27 ` Sergey Y. Afonin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ee869bad-a980-ae8f-22d3-4e213b67e552@rosalinux.ru \ --to=mikhailnov@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git