как вы компилите многокомпонентный проект?

CMake, в каждом каталоге свой CMakeLists.

описание компонентов и их зависимостей в одном файле

Видел в одном коммерческом проекте такую систему сборки, основанную на waf.
PS: правда не все в одном файле, а по файлу на компонент.

CMake

что используете вы? насколько это распространено?

для начала, нужно понять что такое «компонент». отдельная папка? модуль? статическая/динамическая библиотека? что насчет ресурсов (иконки/картинки/звуки/тексты/переводы/...)?

распространение проекта как делается, в бинарях или в исходниках?

от этого зависит ответ.

по совокупности фич, для опенсорса под *nix лучше autotools ничего нет (а если устраивает cygwin/mingw — то и под вендой работает). можно как общий makefile на все модули, так и по 1 makefile в каждом модуле.

если распространение в виде исходников (configure;make;make install) не нужно — то можно рассмотреть другие альтернативы. например, jam+ неплох. синтаксис уродливый, но умеет генерировать проекты для xcode и msvs, что очень удобно. но он только компилирует — делать тарболлы и установку и подобное придется другими средствами. поэтому для опенсорса не очень удобно.

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

многие хвалят cmake, на лоре есть много срачей по этому поводу. синтаксис один из самых уродских, что я только встречал. гибкость ниже среднего. в основном надо полагаться на готовые модули, которые есть не для всего. например, если нет готового модуля cmake для подключения нужной тебе внешней библиотеки — придется свой модуль запиливать (намного сложнее чем в autotools, например). make uninstall по дефолту нету, но можно нагуглить как его прикрутить. по ходу срачей, кто-то вроде упоминал, что он позволяет захренячить все в один CMakeLists (то что ты спрашивал). еще один недостаток cmake — это отсутствие стадии configure. т.е. проверять наличие и корректность зависимостей он не умеет. для меня это большой минус.

распространение проекта как делается, в бинарях или в исходниках?

сырцы, положим tar не нужен так как github

для начала, нужно понять что такое «компонент». отдельная папка? модуль? статическая/динамическая библиотека? что насчет ресурсов (иконки/картинки/звуки/тексты/переводы/...)?

положим программа и ее плагины и все это нужно собрать из сырцов.

спасибо за перечисление - почитаем. autoconf наверное самое православное и самое не понятное

CMake или Scons

для опенсорса под *nix лучше autotools ничего нет

Не под *nix, а под gnu toolchain

придется свой модуль запиливать

Ога, 5 строк написать это офигенно сложно.

это отсутствие стадии configure. т.е. проверять наличие и корректность зависимостей он не умеет. для меня это большой минус.

ЩИТО?

еще один недостаток cmake — это отсутствие стадии configure. т.е. проверять наличие и корректность зависимостей он не умеет. для меня это большой минус.

Это настолько большая неправда, что я даже чуть чай из рук не выронил. В CMake есть серия функций CHECK_* которые в очень удобной форме как раз и делают проверки.

http://www.vtk.org/Wiki/CMake:How_To_Write_Platform_Checks

ЩИТО?

ну я примерно так понял то, что писали сторонники cmake во время последнего срача, в котором я принимал участие. если не прав - прошу прощения.

Ога, 5 строк написать это офигенно сложно.

5 строк модуль + 1(?) строка применение модуля. как минимум. это уже в 6 раз больше чем в автотулсах.

хвала CMake!

CMake. С параллельностью сборки всё отлично: если правильно укажете зависимости, то всё будет отлично собираться хоть с make -j10. Зависимости компонентов в одном файле сделать тоже можно, сам делал.

это уже в 6 раз больше чем в автотулсах.

В autotools так хорошо только для тех библиотек, у которых есть pkg-config-совместимая информация, или вообще для любых?

для любых. pkg-config вообще необязателен. можно просто писать

AC_CHECK_LIB([dl], [main], [HAVE_DL=yes;DL_LIBS="-ldl";AC_SUBST(DL_LIBS)])

5 строк модуль + 1(?) строка применение модуля. как минимум. это уже в 6 раз больше чем в автотулсах

Для pkg-config в cmake нужна ровно одна строка. Для не pkg-config в autocrap нужно написать не меньше чем в cmake.

По теме: CMake, естественно.

я выше написал, что надо писать без pkgconfig. покажешь как написать в cmake столько же для такого же результата?

Автокрапщики даже свою документацию не читают? «function should be a function provided by the library». main он в dl проверяет, лол. Теперь вспомним что библиотеки могут быть по путям неизвестным линкеру, а инклуды - компилятору, а ещё под разными префиксами и получаем полстраницы нечитабельной каши на библиотеки.

К слову, приведённый пример на cmake это вообще ${CMAKE_DL_LIBS}

Для общего случая FIND_LIBRARY(DL_LIBRARY NAMES dl)

На самом же деле одна строка или десять совсем не важно, это просто вам мериться нечем. Важно что CMake работает не только на Linux, а ещё важнее что код на нём поддаётся пониманию и правке.

CMake.

cmake -G Ninja .
ninja

CMake ещё не советовали? Рекомендую, одна из лучших систем сборки.

main он в dl проверяет, лол.

и она там есть, прикинь?

Теперь вспомним что библиотеки могут быть по путям неизвестным линкеру

это нормально. это дело юзера, сделать так чтобы пути линкеру стали известны.

К слову, приведённый пример на cmake это вообще ${CMAKE_DL_LIBS}

это не имеет отношения к исходному вопросу.

Для общего случая FIND_LIBRARY(DL_LIBRARY NAMES dl)

о, этого в срачах про cmake не было, и гугл чего-то про это не знает. можно ссылочку в документацию?

На самом же деле одна строка или десять совсем не важно, это просто вам мериться нечем.

меряться даже не собирался. мне незачем.

Важно что CMake работает не только на Linux

сегодня собирал проект, использующий автотулзы, на макоси. несколько дней назад собирал другой проект, использующий автотулзы, на freebsd. много лет назад собирал кучу всего, использующего autotools, под mingw32 на венде. регулярно собираю разное под cygwin. ЧЯДНТ?

да, вот с cmake у меня как-то хуже получается. в 50% случаев у меня он даже в линуксе не работает. наверное, карма плохая.

а ещё важнее что код на нём поддаётся пониманию и правке.

что не меняет факта, что в нем один из самых убогих синтаксисов из всех билд систем.

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

и она там есть, прикинь?

edit: я неправ, ее там нет. это такой традиционный хак, как оказалось, который используют чуть менее чем все :)

CMake решил все мои проблемы со сборкой.

который используют чуть менее чем все

Кстати, в autotools есть возможность сборки в другой директории?

Кстати, в autotools есть возможность сборки в другой директории?

mkdir build
cd build
../configure
make

и она там есть, прикинь?
edit: я неправ

Хоть одним враньём меньше, и на том спасибо.

это нормально. это дело юзера, сделать так чтобы пути линкеру стали известны

Нет, это не дело юзера, это дело системы сборки - взять и собрать, из коробки.

это не имеет отношения к исходному вопросу

Имеет прямое. Просил -ldl? Получи -ldl.

о, этого в срачах про cmake не было, и гугл чего-то про это не знает. можно ссылочку в документацию?

То есть «срачи» были тех кто в глаза не видел CMake с теми кто в глаза не видел CMake? Ожидаемо. Почитайте хоть самую базу того о чём пытаетесь спорить: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:find_library

сегодня собирал проект

Да-да, на локалхосте всё работает, слышали. В это время те же порты FreeBSD пухнут от патчей к autocrap, костыли пришлось даже добавить в инфраструктуру поскольку они нужны в каждом случае использования. Ну и да, про то что есть другие способы сборки нежели один привычный вам который вы насилуете и на макоси, и с mingw и в cygwin вы, конечно, не в курсе. Проекты для IDE - не, не слышал.

что не меняет факта, что в нем один из самых убогих синтаксисов из всех билд систем

Во-первых, это вы пукнули в лужу. Без аргументов, без примеров - просто навоняли. Достаточно характеризует вашу компетентность и профессионализм. Во-вторых, признайтесь, вы про cmake и autocrap знаете только что они есть, ничего никогда не собирали, что уж там говорить о том чтобы своё писать. Иначе в каком пьяном угаре можно такое утверждать?

Это вы пытаетесь сейчас кому-то доказать что ясные и простые команды cmake чем-то более убоги по сравнению с десятками килобайт нагромождения макросов и sh кода, обычных для autocrap типа http://trac.imagemagick.org/browser/ImageMagick/trunk/configure.ac, или может быть с той мегабайтной помойкой которая из этого генерится?

Да уже упомянутых

FIND_LIBRARY(DL_LIBRARY NAMES dl)

vs.

AC_CHECK_LIB([dl], [main], [HAVE_DL=yes;DL_LIBS="-ldl";AC_SUBST(DL_LIBS)])

нормальному человеку на вашем месте хватило бы чтобы язык прикусить.

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

Аргументов нет у вас, как нет и малейшего представления ни о autocrap ни о cmake, и умнее было бы с вашей стороны спор вообще не начинать (хотя вам, я смотрю, ближе даже не споры а срачи). Теперь-то уже поздно сливаться, вы сели в лужу конкретно, хотя всё понятно было уже после «кто-то вроде упоминал, что он позволяет» и «отсутствие стадии configure. т.е. проверять наличие и корректность зависимостей он не умеет».

Нет, это не дело юзера, это дело системы сборки - взять и собрать, из коробки.

а, т.е. в cmake используется libastral, который сам угадывает, откуда либы брать? окай.

Имеет прямое. Просил -ldl? Получи -ldl.

никто ничего такого не просил. просили показать, как это делается в автотулсах без pkg-config.

Почитайте хоть самую базу того о чём пытаетесь спорить

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

вы, конечно, не в курсе

я использовал и использую несколько различных систем сборки.

Достаточно характеризует вашу компетентность и профессионализм.

сказал кто?

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

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

autotools успешно применяю уже около 10 лет. как раз перед написанием этого поста ковырялся в configure.ac одного из своих проектов.

Это вы пытаетесь сейчас кому-то доказать что ясные и простые команды cmake чем-то более убоги по сравнению с десятками килобайт нагромождения макросов и sh кода

это в срачах было. сравнивали. в cmake кода получалось больше, чем в autotools, во всех рассмотренных случаях.

хотя всё понятно было уже после «кто-то вроде упоминал, что он позволяет» и «отсутствие стадии configure. т.е. проверять наличие и корректность зависимостей он не умеет»

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

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

Круто, спасибо.

lowercase

Case-insensitive.

Нет, ну серьёзно. CMake имеет свои недостатки, среди которых - достаточно примитивная грамматика языка и много хардкода для общих случаев, но это так специально.
Такой язык проще читать, помнить и парсить. Действительно, он объёмнее автотулзового, но зато последний без специального изучения смахивает на sed, awk или Ruby.

Ну и наконец, вот кому пришла в голову мысль использовать макропроцессор m4 для системы сборки?

P. S.: сразу говорю (хотя и так понятно), что с autotools знаком исключительно в режиме «открыть configure.ac, ужаснуться, закрыть configure.ac».

CMake имеет свои недостатки

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

Такой язык проще читать, помнить и парсить.

ruby я не знаю, с sed и awk ничего общего. но можно использовать bourne shell. а так — m4 там, как ты и написал, да и то, только в configure.ac. тоже не самый красивый синтаксис, зато достаточно гибкий.

а, т.е. в cmake используется libastral, который сам угадывает, откуда либы брать? окай.

Если ты думаешь что чтобы найти на целевой системе библиотеки нужен libastral, тебя ждёт удивление.

никто ничего такого не просил. просили показать, как это делается в автотулсах без pkg-config

Ты показал как делается dl без pkg-config, я тоже показал.

судя по тому, что этот find_libraries (lowercase!) никто в срачах пока не упомянул

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

— это далеко не «самая база». даже гугл не нашел

То есть у тебя даже не хватило ума просто заглянуть в документацию?

да ты и сам не знал как оно пишется на самом деле. и, вероятно, как применяется - тоже не в курсе

То есть ты даже не знаешь что cmake case-insensitive?

autotools успешно применяю уже около 10 лет
а, ну и еще на работе специалисты соотвутствующего профиля исследовал возможность использования cmake для нашего проекта

Никто в это не поверит. Если бы ты был знаком с миром unix 10 лет и разрабатывал бы какие-то проекты, ты бы был, во-первых, на порядок компетентнее, даже в инструментах с которыми плотно не работал, хотя бы в той степени которая позволяет почитать документацию, во-вторых, был бы достаточно зрелым и дорожил бы репутацией, чтобы осознавать границы своей компетенции и не начинать спор о том в чём не разбираешься и тем более не делать не аргументированные заявления. Да что там - больше 16 лет после твоих «в срачах не упомянул» и «гугл не нашёл» я тебе не дам. В 6 лет начал ковырять autotools? Похвально. Но одно это специалистом тебя не сделает.

сказали, что никуда оно не годится.

Наверное тоже у срачей спросили?

я не утверждал, что хорошо знаю cmake. только на уровне ниасилившего юзера

С этого надо было начинать. Если ты даёшь человеку совет в чём-то, подразумевается что ты в этом чём-то достаточно разбираешься. Так уж принято в профессиональной среде - настоящей, а не твоих выдуманных «специалистов соответствующего профиля». Ты же, по сути, ляпнул от балды - поступил непрофессионально и просто по-человечески подло, обманул человека который тебе мог доверять.

ув. slovazap, у меня к тебе маленькая просьба, если не затруднит — не используй в общении со мной всякие дебильные фразочки, типа пуканья в лужу и прочего школоло

Извини, но затруднит. Ты потерял привилегию уважительного к тебе отношения, первым проявив неуважение к участникам форума.

на что мне в принципе пофиг

Подросткам всегда на всё пофиг, а стоило бы задуматься.

Касательно того что код cmake объёмней, это ещё одно голословное утверждение и ещё одна неправда.

Вот пара проектов использующих одновременно и autocrap и cmake:

SDL2:

% find . -name CMakeLists.txt -exec cat {} \; | wc
    1236    3322   42884
% find . \( -name configure.in -o -name configure.ac -o -name Makefile.am \) -exec cat {} \; | wc
    3074    8442  109856

llvm:

% find . -name CMakeLists.txt -exec cat {} \; | wc
    3729    6322   91549
% find . \( -name configure.in -o -name configure.ac -o -name Makefile.am \) -exec cat {} \; | wc
    3615   12849  139141

Если ты думаешь что чтобы найти на целевой системе библиотеки нужен libastral, тебя ждёт удивление.

/usr/local/mylib-1.0/lib/libmylib.so
/usr/local/mylib-1.1/lib/libmylib.so

как cmake угадает какая из них нужная? у меня, например, таким образом установлено 4 разных версии ffmpeg.

Ты показал как делается dl без pkg-config, я тоже показал.

речь шла о произвольной либе, которой нет в pkgconfig (и в модулях cmake, по аналогии).

То есть у тебя даже не хватило ума просто заглянуть в документацию?

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

То есть ты даже не знаешь что cmake case-insensitive?

нет. я ведь им не пользуюсь.

на остальной школобред даже отвечать не хочется.

ruby, sed, awk

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

Ну и да, я вроде пояснил, что указанные недостатки таковыми не являются...

вбил cmake FIND_LIBRARY в гугл, и на первой странице выдачи документации не оказалось

остальной школобред

по делу сказать нечего?

как cmake угадает какая из них нужная?

Внезапно, cmake используется не только для нужд локалхоста, поэтому он учитывает стандартные правила (описанные в той же несчастной доке). Ну а если всё равно нужно, то у find_library есть параметр PATHS с очевидным предназначением.

To recap: твоя ошибка в том, что ты пытаешься выдать собственное незнание функционала за его отсутствие. Строго говоря, это 4.2.

configure.in

это автогенеренный файл. можно цифирки без него?

Внезапно, cmake используется не только для нужд локалхоста

а причем тут это? там выше человек с пеной у рта доказывает, что cmake сам угадывает откуда брать либы. я поинтересовался как именно он это делает.

то у find_library есть параметр PATHS с очевидным предназначением.

т.е. чтобы указать линкеру путь к библиотеке, нужно менять CMakeLists? забавно :)

To recap, твоя ошибка в том, что ьы пытаешься выдать собственное незнание функционала за его отсутствие. Строго говоря, это 4.2.

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

это автогенеренный файл. можно цифирки без него?

тфу, попутал. это просто старое название. этот файл уже никто не использует лет 5.

вобщем, мне на цифры возразить нечего, если cmake устраивает — пользуйся на здоровье.

когда я писал что в cmake код объемнее — я честно сказал, что измерения основаны на результате срачей на лоре. местные cmake-эксперты приводили свои примеры, автотулсеры свои. как-то вот получилось что автотулс лаконичнее. видимо, на других примерах есть экономия.

Ну не все так отлично.. Есть у него глюки с генерацией файлов.

• «Угадывает», совершенно верно. По вполне заданным правилам.
• Конечно, необязательно. Можно передать cmake соответствующий параметр (-DNAME=PATH) и соответствующий find_library будет заменён пользовательским значением.
• Ты выше утверждал, например, что cmake не имеет стадии проверки наличия библиотек.

«Угадывает», совершенно верно. По вполне заданным правилам.

ок. что это за правила? например, установлены /usr/local/ffmpeg-2.0/lib/*.so и /usr/local/ffmpeg-2.1/lib/*.so.

какую из этих версий он «угадает»?

Можно передать cmake соответствующий параметр (-DNAME=PATH)

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

Ты выше утверждал, например, что cmake не имеет стадии проверки наличия библиотек.

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

Можно передать cmake соответствующий параметр (-DNAME=PATH)

собственно, из всего этого вытекает пара вопросов :)

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

вопрос нумбер 1: стандартный модуль ffmpeg (либо для других библиотек, по аналогии) позволяет слинковаться с ffmpeg из произвольного префикса, а не из префикса куда будем ставить нашу программу? (по аналогии — в автотулсах эта инфа есть в ./configure --help)

вопрос нумбер 2: cmake каким-либо образом позволяет выяснить, какие параметры в комстроку для этого нужно написать, без полного прочтения CMakeLists и/или гугленья?

upd: да, предположим, программа существующая, произвольно взятая. чтобы я, например, мог ее скачать, и проверить ответы :)

ок. что это за правила? например, установлены /usr/local/ffmpeg-2.0/lib/*.so и /usr/local/ffmpeg-2.1/lib/*.so.
какую из этих версий он «угадает»?

Ни одну. Пути нестандартные.

Ни одну. Пути нестандартные.

slovazap писал:

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

разве не этот случай имелся ввиду?

(если что, я ушел спать, отвечу завтра, если будет на что отвечать :)

configure.in

это автогенеренный файл

Доооо, вот они - 10 лет autotools за плечами. Позорная напыщенная школота.

Можно задать префикс(-ы) для поиска всего через переменную окружения CMAKE_PREFIX_PATH (через двоеточие).
Например:

# export CMAKE_PREFIX_PATH="/usr/local/my-ffmpeg-version-41:/opt/my-qt-version-41"
# cmake ..

Всё остальное сильно различается и зависит от структуры CMakeLists. Вообще, есть ncurses'ный редактор т. н. кэша CMake: ccmake <build-dir>, позволяющий посмотреть и поменять всё, что там хранится.
Если использовать стандартные средства поиска (есть интеграция с pkg-config, есть кастомные модули для распространённых/сложных библиотек), то всё, что можно поменять, кладётся в кэш.