CMake 3.0

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

Что там и как должно быть - об этом разработчики ФМ и ОС пользователей спрашивать не станут. Никогда не качал из сети в архивах виндовые файлы tumbs.db ?

Типичная же свалка в .gitignore проектов на autotools к этому отношения не имеет.

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

Да, с маком вкуснее! Тёплые булочки. 8-))

autotoolsокапец когда?

Увы, CMake ужасно не интуитивен и костылен: сужу по тредам на ЛОРе.

Жаль, что QMake и QBS намертво привязаны к Qt. Если первый - удобная замена CMake, генерирующая читабельные Makefile, то второй - полноценная система сборки без архаичных костылей в виде make с языком декларативного синтаксиса:

import qbs.base 1.0

Product {
    property string appViewerPath: "common/"

    condition: Qt.core.versionMajor === 5

    type: ["application", "installed_content"]

    Depends { name: "Qt.core" }
    Depends { name: "Qt.quick"; condition: Qt.core.versionMajor === 5 }
    Depends { name: "cpp" }

    cpp.includePaths: [appViewerPath]

    Group {
        prefix: appViewerPath
        files: [
            "*.cpp",
            "*.h"
        ]
    }
}

Увы, требует несколько весомых компонентов из Qt5.

libtool - и этого достаточно

Когда в qbs появится то обилие find модулей как в cmake, тогда и можно будет сравнивать. а сейчас альтернативы cmake нет.

А premake и прочие тоже пока ни о чем

cmake "-DCMAKE_FIND_LIBRARY_SUFFIXES=.a;.so"

Убогий и неочевидный синтаксис

Проблема в том, что в autotool множество синтаксисов. Там же куча различных сущностей (autoconf, automake, autoheader ...) у каждой из которых свой собственный конфиг со своим синтаксисом.

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

Неосилятор детектед, ты про VPATH builds слышал вообще? Вот как всегда, мануал не читают, как билд системы работают не знают, а мнение имеют.

Или вспомним про степень поддержки autotools на Windows.

Это единственный серьёзный аргумент в пользу CMake, кстати.

Она работает всегда, если её только специально не ломать неправильным использованием макросов.

Их авторы соревнования могут устраивать по степени упоротости игнорируемых паттернов.

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

И что ты этим доказал?

Типичные пользователи CMake --- такие же недоумки и среди них ещё меньше людей отдаленно понимающих как работают системы сборки.

О! Ресет высказался!

Проблема в том, что в autotool множество синтаксисов.

autotool

Синтаксисы? Там вообще нет никаких своих синтаксисов. Используются три основных инструмента: POSIX shell, m4 и make. Если ты их знаешь/понимаешь, то ты знаешь/понимаешь более ли менее всё, даже без чтения документации.

Там же куча различных сущностей (autoconf, automake, autoheader ...) у каждой из которых свой собственный конфиг со своим синтаксисом.

Вот упорыш... Расскажи-ка подробнее про «конфиги autoheader» со своим синтаксисом для примера, чтобы быть конкретным.

Для пользователя вообще релевантен только autoconf, который суть есть shell + m4 и automake (если используется), который суть есть make с подстановками.

Это такой make, только не make и с поломанной обратной совместимостью со старым не-make?

Нет, это система сборки с декларативным языком описания, читается/пишется проще чем make. По-сути это более универсальная замена autotools. Отличный продукт!

Насколько оно уже юзабельно?

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

Я от прочтения мануала по GNU/make чуть не поехал. А тут еще cmake, qmake, ninja. Куда ж столько

который суть есть shell + m4 и automake (если используется), который суть есть make с подстановками.

То есть ты сам насчитал уже как минимум три различные сущности. Если ты считаешь это нормальным, то упорыш как раз ты.

Я от прочтения мануала по GNU/make чуть не поехал. А тут еще cmake, qmake, ninja. Куда ж столько

Аналогично :) Открой для себя cmake, а про make забудь как о страшном сне.

cmake парсит исходники и проверяет сам зависимости .h/.c/.cpp файлов.

Например, если поменялся .h - то cmake находит все .c файлы в проекте, которые его включают, и пересобирает их.

Для automake придется вручную указывать зависимости, что очень неудобно для большого проекта, например, забыл указать зависимость, зависимый объектник не пересобрался, а потом ловишь segfault и тратишь время чтоб понять отчего это.

Оно не умеет разруливать одинаковые имена файлов в разных файлах

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

Удален код для поддержки совместимости с версией CMake 2.4.

А что там с поддержкой CMake 2.8? Оставили?

Столько срача на пустом месте:)

Кто говорит, что cmake не нужен скорее не разу не пробовал пользоватся им. Как уже выше подметили, мне не нужно создавать кучу файлов, что бы сконфигурировать проэкт — достаточно создать один, при чем я могу в каждой отдельной директории я могу сделать другую сборку этого же приложения, что очень удобно. При autotools надо распаковывать тарболы в несколько папок — такая каша иногда получается. Однако некоторые вещи в cmake не очевидны или немного не удобны. Но это можно исправить в новой версии cmake. И кстати я очень рад, что синтаксис свой, а не скопировали где-нибудь. Это очень удобно, так как кому-то может нравится или не нравится синтаксис или архитектура языка. Зависимости очень ослабили позиции cmake. Чем меньше зависимостей у cmake тем лучше. Но на самом деле не все так просто, иначе бы все перешли на cmake с autotools. И думаю оба инструмента еще долго будут нужны.

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

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

Чем custom_command не угодило?

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

Что мне не нравится в cmake так это то, что я не могу скомбинировать свой Makefile с ним. Все таки хотелось бы больше свободы действий.

Вдруг поможет http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html

Не очень понял. Через add_custom_command задается и цель и зависимости, поэтому всё прозрачно. Потом это всё можно обернуть в макросы для добавления однотипных правил. Посмотри сорцы каких-нибудь FindFlex и FindBison. Там всё через add_custom_command делается.

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

Это все понятно. Хочется написать свой шаблон, по которому сгенерился Makefile, а не только задавать параметры шаблонов. Есть к примеру готовые шаблоны, а некоторые можно было бы написать самому. В результате сгенерированый Makefile будет таким, как тебе нужно. Сейчас в него попадает очень много информации, которая может быть избыточной — то есть она есть, но никакой пользы не несет. Таким образом написал например главный шаблон, хочешь включаешь свои, хочешь готовые. Чаще всего, думаю, пара своих шаблонов было бы достаточно.

То есть ты сам насчитал уже как минимум три различные сущности. Если ты считаешь это нормальным, то упорыш как раз ты.

юникс-вей же, для каждой задачи своя утилитка

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

я видел, коммерческий и кроссплатформенный, там ещё свои велосипеды поверх autotools были :)

Так задача одна.

Это противоречит идеологии cmake. Makefile это всего лишь один из backend'ов.

ясно, жаль:)

удобная замена CMake, генерирующая читабельные Makefile

ЗАЧЕМ?

А что там с поддержкой CMake 2.8? Оставили?

Вроде собирается всё, по крайней мере, мои проекты.

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

Была попытка заменить синтаксис CMake на Lua, но подход был признан неудачным и оставили как есть. Где-то в рассылке можно найти аргументы за и против. Кроме обратной совместимости, которая, несомненно, важна, ещё приводили аргументы, что билд скрипты того же SCons со временем превращаются в свои мини-проекты, что затрудняет дальнейшую поддержку.

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

Не хочется обижать защитников autotools, но собирать сложные проекты с их помощью без скотча и чёрной магии очень сложно - это факт. Яркий пример тому, какая-нибудь embedded SDK с бинарными блобами завязанная на не самый свежий toolchain в корневую систему которой требуется добавить несколько новых пакетов (тоже использующих autotools), учтём кросс-компиляцию и желание одновременно иметь различные конфигурации сборки типа debug и release и получим часы незабываемых приключений в зоопарке версий make, autoconf, automake, libtool с подпиливанием configure скриптов sed'ом, обмазывания всего этого процесса bash'ем и прочих занимательных и продуктивных вещей.

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

cmake парсит исходники и проверяет сам зависимости .h/.c/.cpp файлов.

Даже лучше, кажется именно в CMake 3.0 добавили в тулчейн переменную CMAKE_DEPFILE_FLAGS_CXX, содержимое которой добавляется в командную строку компилятора, указывая ему куда положить собранные зависимости компилируемого исходного файла. За счёт этого проверка зависимостей происходит всегда корректно и максимально быстро, и для Makefile и для Ninja.

То есть ты сам насчитал уже как минимум три различные сущности.

Вопрос только в том, причем тут autotools, клован.

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

Ложь и провокация!

Зависимости строятся автоматически через $CC -M, так что если у тебя чего-то там сегфолтится, то ты неосилятор, ибо неправильно используешь autotools. Документацию, к бабке не ходи, не читал...

Вот так достижение, в autotools это было сто лет в обед как.

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

Из личного опыта источник этой проблемы отнюдь не в языке, в проектах на CMake я тоже часто добавляю сложную логику по собиранию целей, это диктуется необходимостью. И результирующий код выглядит трудночитаемым даже для автора. Часто вызываю команды сборки через `cmake -P`. В языке сильно нехватает динамической типизации, структур, нормальных списков, хеш-таблиц и особенно исключений, ибо очень много опечаток интерпретатор может молча проглотить, когда нужно выхлопнуть ошибку. В то же время стандартная библиотека CMake сильно куцая и уродливая. string(), file(), math(), list() — всё это безобразие должно почить в гробу. Я уже не говорю про нормальное присваивание переменных, «if (condition) $A else $B»-конструкции и аналог list compehension в Python.

новомодные системы сборки с блек джеком и декларативным синтаксисом выглядят хорошо в примерах на сайтах для тривиальных проектов

В CMake уже тоже полезли в декларативщину со своими generator expressions. Синтаксис оставляет желать лучшего, по сравнению с тем же QBS на QML.

Например, если поменялся .h - то cmake находит все .c файлы в проекте, которые его включают, и пересобирает их.

Для automake придется вручную указывать зависимости, что очень неудо но для большого проекта, например, забыл указать зависимость, зависимый объектник не пересобрался, а потом ловишь segfault и тратишь время чтоб понять отчего это.

А ещё, в проекте и внутри системных .so бывают .o файлы с одинаковыми именами. Очень весело, когда всесто правильного .o файла из проекта/компилятора в бинарь _автоматически_ засасывается какае-то одноимённое глючащее нечто из системы. Чем больше проект, тем больше вероятность что слишком инициативная автоматика слинкует не с тем, чем надо.

Вот так достижение, в autotools это было сто лет в обед как.

В CMake это диктуется необходимостью поддержки различных бекендов сборки. Напомните, когда уже в autotools добавят поддержку Ninja или Tup?

Для проектов, не использующих Qt, но использующих QMake в качестве системы сборки, может быть полезным распространять ещё и Makefile.

Я, бывает, Makefile правлю.

Если первый - удобная замена CMake

qmake - ориентирован только на типовую конфигурацию, если требуется что-то не стандартное - сразу вылезают грабли.

ситуация 1: берём комп с неправильным установленным временем(моём случае это были платы на x86 и armv7), копируем на него исходники с другого компа с правильным временем, пробуем запустить qmake для генерации Makefile, он запускается и молча висит, смотрим по top/htop/pstree/ps aux чем же «барин» занят, а он генерит в цикле один и тот же Makefile и делает это молча. Решение: поменять дату, руками (целевые устройства не подкл. к интернету, соотв. никакого ntp. )

ситуация 2: кросскомпиляция.... приложение использующее qt only (хотя это на самом деле не так). как рассказать где у нас кросскомпилятор и rootfs - qmake? кросскомпилятор у нас лежит в ${CROSS_COMPILER_ROOT} готовый rootfs со всеми либами в ${ROOTFS}

по поводу кросскомпилятора всё ясно, делаем export PATH='${CROSS_COMPILER_ROOT}/arm-unknown-linux-gnueabihf/bin':${PATH} пишем примерно такой mkspec и кладём его в /usr/share/qt4/mkspecs или указываем у всех include полный путь,

если у нас потребность юзать 2 версии qt (4.8.x и 5.x.x) то писать 2 спека под каждую версию.

#
# qmake configuration for building with arm-unknown-linux-gnueabihf-g++
#

MAKEFILE_GENERATOR      = UNIX
TARGET_PLATFORM         = unix
TEMPLATE                = app
CONFIG                  += qt warn_on release incremental link_prl gdb_dwarf_index
QT                      += core gui
QMAKE_INCREMENTAL_STYLE = sublib

include(../common/linux.conf)
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)

# modifications to g++.conf
QMAKE_CC                = arm-unknown-linux-gnueabihf-gcc
QMAKE_CXX               = arm-unknown-linux-gnueabihf-g++
QMAKE_LINK              = arm-unknown-linux-gnueabihf-g++
QMAKE_LINK_SHLIB        = arm-unknown-linux-gnueabihf-g++

# modifications to linux.conf
QMAKE_AR                = arm-unknown-linux-gnueabihf-ar cqs
QMAKE_OBJCOPY           = arm-unknown-linux-gnueabihf-objcopy
QMAKE_STRIP             = arm-unknown-linux-gnueabihf-strip

load(qt_config)

ок,а как указать qmake где нужный rootfs - он то лежит отдельно, ${CROSS_COMPILER_ROOT} - здесь только сам кросскомпилятор? Решение: совместить ${ROOTFS} и ${CROSS_COMPILER_ROOT}, если они в единственном числе то, это не плохо и даже можно не считать костылём, а если rootfs много, но кросскомпилятор для них 1?

Как сделать это на cmake: пишем armtoolchain.cmake

# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
# specify the cross compiler
SET(CMAKE_C_COMPILER ${CROSS_COMPILER_ROOT}/arm-unknown-linux-gnueabihf/bin/gcc)
SET(CMAKE_CXX_COMPILER ${CROSS_COMPILER_ROOT}/arm-unknown-linux-gnueabihf/bin/g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH ${ROOTFS})
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Итог: Вполне возможно я не осилил и/или моё google foo слабо, но qmake явно не айс даже для компиляции qt only приложений.

Для проектов, не использующих Qt, но использующих QMake в качестве системы сборки, может быть полезным распространять ещё и Makefile.

Поперхнулся печенькой. Генерируемый Makefile содержит настройки сборки заточенный исключительно на ваш localhost, пути, компилятор, прочие мелочи конфигурации.

Где связь?

shell, m4, make, cc -M .... всё это кое-как склеено соплями и скотчем, а где собственно autotools?