LINUX.ORG.RU

Почему в cmake всё так сложно?

 


2

3

внутри обычного Makefile я могу просто написать

cc -std=c99 file.c -o program -lasound
либо
cc -std=c99 file.c -o program `pkg-config --libs alsa`


что нужно сделать в таком случае для cmake?

текущее содержимое CMakeLists.txt
cmake_minimum_required(VERSION 3.2)
project(program C)

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=c99")

set(SOURCE_FILES
    file.c)

add_executable(program ${SOURCE_FILES})

Возникает желание выбросить на помойку этот cmake... документация в стиле «хрен поймешь без бутылки», вот так сразу ее не взять чтобы «прочитал -> сразу понял -> используешь». Туториалы не объясняют что к чему.

ЛОР, помоги.


З.Ы. program и file.c - нарочно измененные имена. Добавление -lasound после -std=c99 не приводит к какому-либо результату.

★★★★★

Последнее исправление: reprimand (всего исправлений: 2)

Ответ на: комментарий от hobbit

Почему-то твои примеры по cmake выглядят намного более красивыми, чем то, что я обычно вижу в чужом CMakeLists.txt...

Потому что это учебный пример.

tailgunner ★★★★★
()
Ответ на: комментарий от xaizek

Официальная документация большая и сложная.

Работа программиста вообще сложная, и документацию читать приходится, прикинь :) Лично я за неделю на море её осилил и с тех пор полюбил автотулзы, хотя до этого тоже негативно к ним относился

Harald ★★★★★
()
Ответ на: комментарий от imb

Я тоже могу прищемить яйца дверью, а потом говорить, что двери неправильные. Если в каком-то суперхардкорном эмбеддеде пути до библиотек прописывают руками, то это исключительно их проблемы.

А речь шла о том, что на тех платформах, на которых есть libalsa, также есть и pkg-config, и если с проектом поставляется .pc-файл, то использовать нужно именно его, а не хардкод или эвристики. А если кому-то нужно что-то заоверрайдить вручную, то CMake это вполне позволяет сделать.

intelfx ★★★★★
()
Ответ на: комментарий от tailgunner

Если проект состоит из одного исходника и одного бинарника, то CMake (как и любая другая система сборки) действительно не нужен.

В остальных случаях он нужен (уместен) ровно настолько же, насколько и любая другая система сборки или генератор системы сборки.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

он нужен (уместен) ровно настолько же, насколько и любая другая система сборки или генератор системы сборки

Вот прям-таки «ровно» и прям-таки «настолько же»? Так что, у него нет преимуществ перед другими?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Очевидно, есть и преимущества, и недостатки. Я там пропустил слова «в общем случае».

intelfx ★★★★★
()
Ответ на: комментарий от EXL

PkgConfig — хорошо, но только в GNU/Linux

и что?

кросплатформенность переоценена

user_id_68054 ★★★★★
()
Ответ на: комментарий от Harald

tailgunner'у, видимо, не понравилось моё отношение к autocrap, поэтому я переформулирую свою мысль более нейтрально: ты, конечно, молодец, что прочёл доку по нему, но какой смысл в пользовании сложным и неудобным инструментом, если есть более удобный его аналог с как минимум тем же набором функций?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Harald

Мы говорим про конкретный проект (alsa), в котором есть поддержка pkg-config.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

tailgunner'у, видимо, не понравилось моё отношение к autocrap

Мне не понравилось, что твой пост был неспровоцированной грубостью без всякого полезного содержимого. Но за -7 приношу извинения - следовало просто удалить.

tailgunner ★★★★★
()
Ответ на: комментарий от intelfx

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

и неудобным инструментом

в чём конкретно заключаются неудобства?

с как минимум тем же набором функций?

как в CMake запилить кросскомпиляцию, когда проект собирается на одной платформе, будет выполняться под другой и выдавать результат для третьей (опционально)

я так понимаю, для CMake придётся ручками названия платформоспецифичных тулзов вписывать в скрипт, вместо ./configure --build=xxx --host=yyy --target=zzz

P.S tailgunner можешь вот это вот www.linux.org.ru/forum/development/12694399?cid=12695429 тоже за 5.2 удалить

Harald ★★★★★
()
Ответ на: комментарий от Harald

в чём конкретно заключаются неудобства?

В большом количестве boilerplate-кода.

как в CMake запилить кросскомпиляцию, когда проект собирается на одной платформе, будет выполняться под другой и выдавать результат для третьей (опционально)

Последнее требование не имеет никакое отношение к кросс-компиляции, а вообще вот так:

https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html#cross-compiling

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

а этот ARM.cmake кто ручками набивал, и почему его содержимое не есть «большое количество boilerplate-кода»? И так для каждой архитектуры портянку писать?

Harald ★★★★★
()
Ответ на: комментарий от Harald

почему его содержимое не есть «большое количество boilerplate-кода»

Потому что это не «большое количество», а десять значащих строк.

И так для каждой архитектуры портянку писать?

Ты мог заметить, что в этом ARM.cmake единственная ARM-специфичная деталь — это передача компилятору флагов выбора ABI и набора инструкций. Их можно передавать через -DCMAKE_<LANG>_FLAGS, в каковом случае toolchain-файл становится универсальным для всех GCC-подобных тулчейнов.

В новой редакции комментария я привёл ссылку на официальную документацию — как ты можешь видеть, там всё ещё более компактно, а для некоторых тулчейнов (например, clang) вообще достаточно лишь записать требуемую характеристику платформы в специальную переменную.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от Harald

Я то это знаю. Но вот если объяснять людям, что в autotools нет ничего страшного, то это проще сделать на материале небольшого объёма.

xaizek ★★★★★
()
Ответ на: комментарий от i_gnatenko_brain

необходимостью знать дополнительно 3 языка.

Шелл должен знать каждый, а m4 уж точно не хуже фантастически ублюдочного языка CMake.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

m4 уж точно не хуже фантастически ублюдочного языка CMake

cmake'овский язык интуитивно-понятный, а вот m4.... это жесть.

/me умеет и autotools и CMake и ему не нравится ни то ни другое. но если из этих двух выбирать одно, то я выберу CMake.

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от tailgunner

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

А вообще, за 2 с небольшим года поддержки N пакетов в Fedora самыми безпроблемными являются те, которые используют CMake. Это просто наблюдение.

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от Harald

к счастью, я autocrap давно не использую в своих проектиках, но приходилось писать парочку.

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от i_gnatenko_brain

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

Ты первый встреченный мной в сети человек, который не ненавидит язык CMake.

tailgunner ★★★★★
()

благодарю i-rinat, EXL, intelfx и остальных за полезные ответы! вы действительно очень помогли

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

reprimand ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Тот случай, когда система сборки более упорота, чем язык.

расскажи какие ты знаешь НЕупоротые языки

Даже в qbs меньше писанины, а он не заточен только под плюсы, в отличии от.

я не пишу на плюсах и не собираюсь

reprimand ★★★★★
() автор топика
Ответ на: комментарий от i_gnatenko_brain

cmake'овский язык интуитивно-понятный

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

Почему? Хрен его знает, таким его сделали.

reprimand ★★★★★
() автор топика
Ответ на: комментарий от i_gnatenko_brain

нет, не видел, но подозреваю что там ничего хорошего =)

мой пост выше был не к оправдыванию других систем, а просто к тому, что на cmake тоже нужно тратить время, и оно несоизмеримо бОльшее по сравнению с make

reprimand ★★★★★
() автор топика
Ответ на: комментарий от reprimand

оно несоизмеримо бОльшее по сравнению с make

тут я с тобой не соглашусь. я до сих пор не особо понимаю как в make работают всякие там % и ifeq.

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от i_gnatenko_brain

как в make работают всякие там % и ifeq

еще не пользовался...

reprimand ★★★★★
() автор топика
Ответ на: комментарий от intelfx

а вот systemd использует таки autotools, как мог великий разработчик всех времен и народов Поттеринг выбрать для своей божественнной системы инициализации плохую негодную систему сборки? :P

Harald ★★★★★
()

Кстати, я вот задался вопросом и не нашёл с лёту ответ, даже на cmake.org: а cmake поддерживает применение в проекте каких-нибудь языков, кроме C и C++?

hobbit ★★★★★
()
Ответ на: комментарий от Harald

слишком толсто.

у него и выбора то не было особо - autocrap | CMake. видимо, раньше он использовал autocrap и он ему больше нравился. Потом, кстати, Harald (нет, не ты), фиксил баги там: https://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-180000-sed-forks/

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от i_gnatenko_brain

Я просто не нашёл список официально поддерживаемых языков, как это ни смешно...

hobbit ★★★★★
()
Ответ на: комментарий от tailgunner

На самом деле да, это действительно проблема. Я как-то раз пытался собрать Gentoo на n900. Кросскомпиляция отпала довольно быстро, поскольку очень здоровая часть софта в этом вашем лялексе просто не может быть кросскомпилирована из-за тех же автолулзов (многие тесты предполагают запуск бинарников при сборке и т.п.). После чего я поставил distcc и подключил кросскомпилятор на десктопе. На самой n900 в итоге запускались только configure и make. Так вот, в таких условиях практически для каждого пакета configure отрабатывал медленнее чем make. Иногда в разы.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

да, это действительно проблема. Я как-то раз пытался собрать Gentoo на n900

Само по себе уже забавно.

я поставил distcc и подключил кросскомпилятор на десктопе. На самой n900 в итоге запускались только configure и make. Так вот, в таких условиях практически для каждого пакета configure отрабатывал медленнее чем make

Надо же, какая неожиданность - у N900 медленный процессор.

tailgunner ★★★★★
()
Ответ на: комментарий от reprimand

мне по душе самые обычные мейкфайлы

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от reprimand

Без чтения доков и гуглежа во все поля в нем сложно что-то сделать вот так сразу.

«Что-то» — это что? Такое утверждение справедливо для любого языка и почти любого ПО в принципе.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Что следует считать «достаточным» знанием языка CMake?

Ну, например, способность логично обосновать наличие () после endif (нет, ответ «в скобках может писаться выражение в if» не катит). Продемонстрируй интуицию.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.