Состоялся (https://blog.kitware.com/cmake-3-6-0-available-for-download/) релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.6 (http://www.cmake.org/), выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD.CMake примечателен предоставлением простого языка сценариев, средствами расширения функциональности через модули, минимальным числом зависимостей (нет привязки к M4, Perl или Python), поддержкой кэширования, наличием инструментов для кросс-компиляции, поддержкой генерации файлов сборки для широкого спектра систем сборки и компиляторов, наличием утилит ctest и cpack для определения сценариев тестирования и сборки пакетов, утилитой cmake-gui для интерактивной настройки параметров сборки.
Основные улучшения (https://cmake.org/cmake/help/v3.6/release/3.6.html#new-features):
- В генератор файлов сборки для Visual Studio 14 2015 добавлена поддержка инструментария Clang/C2 (используется опция "-T v140_clang_3_7");
- В команду list() добавлена подкоманда FILTER для фильтрации списка элементов по маске, заданной при помощи регулярного выражения;
- Добавлена переменная CMAKE_TRY_COMPILE_TARGET_TYPE для информирования команды try_compile() о необходимости сборки статической библиотеки вместо исполняемого файла, что может оказаться полезным для систем кросс-компиляции, которые не могут связывать исполняемые файлы без отдельных флагов или скриптов;- Добавлена поддержка свойства {язык}_CLANG_TIDY и переменной
CMAKE_{язык}_CLANG_TIDY для указания генератору makefile и генератору Ninja-файлов о необходимости запуска clang-tidy вместе с компилятором для языков C/С++;
- В модуль ExternalProject добавлена опция "GIT_SHALLOW 1" для создания shallow-клона репозитория и добавлена поддержка рекурсивной инициализации субмодулей Git;
- В модуль InstallRequiredSystemLibraries добавлена опция CMAKE_INSTALL_UCRT_LIBRARIES для применения локального развёртывания универсальных CRT-библиотек Windows при помощи Visual Studio 2015;
- Функциональность Compile Features теперь учитывается возможности, поддерживаемые в компиляторах Intel C++ версий с 12.1 по 16.0 на платформах UNIX;
- Объявлены устаревшими модуль CMakeForceCompiler и генератор сборочных файлов для Visual Studio 7 .NET 2003. Прекращена поддержка генератора для Visual Studio 7 и Visual Studio 6.URL: https://blog.kitware.com/cmake-3-6-0-available-for-download/
Новость: https://www.opennet.ru/opennews/art.shtml?num=44747
А авторы хотябы в этом релизе догадались, что такое --libdir, --bindir, --sbindir ли может хотябы разобрались в отличиях --prefix и DESTDIR ?
Сто лет уже как есть https://cmake.org/cmake/help/v3.6/module/GNUInstallDirs.html
Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных приводит к нужному результату.
> Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
> приводит к нужному результату.Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.
>> Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
>> приводит к нужному результату.
> Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.Вы наверное их делаете сами. Вы назовите конкретный пакет.
Ведь ни один из перечисленных в новости такими свойствами не обладает.
Словом, назовите конкретный пакет, я посмотрю как он сделан.
Подтверждаю. Это работает везде. Это у вас самого проблемы на вашем локалхосте, разбирайтесь со своими настройками, почему у вас это нигде не работает.
Говорят же вам люди - работает.
Например: https://github.com/search?l=cmake&q=include%28GNUInstal...
eiskaltdcpp-qt подойдёт? А так куча других могу привести.n=eiskaltdcpp && cd /tmp && git clone git://github.com/$n/$n.git && cd $n && F="-march=native -msse3 -O3 -fomit-frame-pointer -pipe -DNDEBUG" && cmake -LA -DCMAKE_C_FLAGS_RELEASE="$F" -DCMAKE_CXX_FLAGS_RELEASE="$F" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -DLIBDIR=lib64 -DUSE_ASPELL=ON -DWITH_SOUNDS=ON -DUSE_MINIUPNP=ON -Dlinguas="en ru" && make -j4 && sudo make install && cd .. && rm -rf $nА вот в проектах БЕЗ cmake, приходится вот так вот извращаться.
n=smplayer && cd /tmp && svn co https://subversion.assembla.com/svn/$n/$n/trunk $n && cd ./$n && vim Makefile
2: PREFIX=/usr
16: QMAKE=qmake-qt5
17: LRELEASE=lrelease-qt5
n=smplayer && make -j4 && sudo make install && cd .. && rm -rf $n
> vim Makefilemake -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
не кактит, да?
У человека просто cmake головного мозга, или по простому каша в голове.
>> vim Makefile
> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
> не кактит, да?Нет, не катит. PREFIX не изменяется.
>>> vim Makefile
>> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
>> не кактит, да?
> Нет, не катит. PREFIX не изменяется.Разумеется, что такое переменные окружения, авторы CMake сначала тоже не знали, все через текстовый файл. Новая целевая архитектура? - готовь новый файл -DCMAKE_TOOLCHAIN_FILE=path/to/file
>>>> vim Makefile
>>> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
>>> не кактит, да?
>> Нет, не катит. PREFIX не изменяется.
> Разумеется, что такое переменные окружения, авторы CMake сначала тоже не знали, все
> через текстовый файл. Новая целевая архитектура? - готовь новый файл -DCMAKE_TOOLCHAIN_FILE=path/to/fileАвторы СMake дали возможность читать ENV переменные, то что это большинство не использует, точно не проблема CMake и его разработчиков.
https://gist.github.com/dhamp/4063692d2c620caa8a01a164082f6827
> >> vim Makefile
> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
> не кактит, да?
> Нет, не катит. PREFIX не изменяется.Ну, не знаю, что Вы там курите...
$ make -f x.mk dummy
echo internal
internal$ make -f x.mk PREFIX=external dummy
echo external
external$ cat x.mk
PREFIX = internaldummy:
echo ${PREFIX}
$
Не подойдет, в нем QUI с использованием qmake собирается. А Qmake, как я говорил ранее, гораздо лучше чем CMake. Там люди понимали что творят. Лучше вы посмотрите на проект, который необходим для Qt-3d https://github.com/assimp/assimp.
> А Qmake, как я говорил ранее, гораздо лучше чем CMake. Там люди понимали что творят.Толсто.
>Не подойдет, в нем QUI с использованием qmake собирается.В eiskaltdcpp Qt UI собирается с помощью qmake? Видать я, как один из авторов, не в курсе.... вот же не задача.
Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил и CMake. И про qmake ты говоришь вещи, которые для видевшего этот ад и израиль давно не новость.
> Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил
> и CMake. И про qmake ты говоришь вещи, которые для видевшего
> этот ад и израиль давно не новость.Люди просто не собирали чужие пакеты в таких количествах кросс-компиляторами для разных целевых систем. Работая на PC и для PC косяки не видны и мир гораздо проще. А на счет "утерли", если от этого их самолюбие станет больше, так я только рад за них.
>> Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил
>> и CMake. И про qmake ты говоришь вещи, которые для видевшего
>> этот ад и израиль давно не новость.
> Люди просто не собирали чужие пакеты в таких количествах кросс-компиляторами для разных
> целевых систем. Работая на PC и для PC косяки не видны
> и мир гораздо проще. А на счет "утерли", если от этого
> их самолюбие станет больше, так я только рад за них.Несомненно, на non PC переменные окружения видимо по-другому окружают.
Несчастные пользователи CMake вынуждены добавлять собственные переменные типа LLVM_LIBDIR_SUFFIX или ASSIMP_LIB_INSTALL_DIR.И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?
Почему Вы эти вопросы задаете на opennet.ru, а не
в багтрекере проекта?
Задаю, разумеется, и в проектах. Баги завожу. Только проблема в том, что ошибки в проектах делятся на те, которые обусловлены самим фактом использования CMake и те, которые допускают авторы проекта. А здесь я, фактически не задаю вопросы, а констатирую факты в надежде, что хоть кто-нибудь начиная собственный проект, задумается о выборе средств.
> И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?И в чём же он не правильно его понимает?
http://stackoverflow.com/questions/1815688/how-to-use-ccache...
Описания по ссылке проблем CMake как ни странно нет, а вот у людей желания использовать его не согласно документации хоть отбавляй, но виноват как всегда кто-то другой.
Ну вот вам пример. Для того чтобы использовать ccache в файл CMakeLists.txt добавляют следующие строки:# Configure CCache if available
find_program(CCACHE_FOUND ccache)
if(CCACHE_FOUND)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache)
endif(CCACHE_FOUND)https://www.virag.si/2015/07/use-ccache-with-cmake-for-faste.../
Авторы, использующие CMake этого, практически никогда не делают.
Между тем, для нормальных систем, чтобы использовать CCACHE достаточно задать переменную
CC="/usr/bin/ccache gcc". Однако CMAKE прочитав значение переменной CC начнет делать предположения. И получится, что в качестве компилятора CMake выберет "/usr/bin/ccache", а "gcc" - сочтет первым аргументом.Вы разумеется скажете, что это не проблемы CMake, а тех кто его использует.
Я же считаю, что это проблема CMake потому, что CMake делает лишние телодвижения там, где они вовсе не нужны и приводят к ошибкам.
Видимо я всегда делал что-то не так, если мне нужен был ccache.
Всего то вызывал так: cmake ${path_to_src} -DCMAKE_CXX_COMPILER=/lib/ccache/bin/g++ -DCMAKE_C_COMPILER=/lib/ccache/bin/gcc. И оно работало.
ls -l /usr/lib/ccache/bin/{gcc,g++}
lrwxrwxrwx 1 root root 15 Apr 21 22:24 /usr/lib/ccache/bin/g++ -> /usr/bin/ccache
lrwxrwxrwx 1 root root 15 Apr 21 22:24 /usr/lib/ccache/bin/gcc -> /usr/bin/ccache
>Вы разумеется скажете, что это не проблемы CMake, а тех кто его использует.Можно придумать проблему и героически её решить, но зачем, когда её никогда не было ?
>Я же считаю, что это проблема CMake потому, что CMake делает лишние телодвижения там, где они вовсе не нужны и приводят к ошибкам.
1 раз сделать симлинк(если собиратель пакета ccache его уже не сделал), это же столько лишних действий.....
Вы молодец конечно. Символические ссылки - это один из способов использовать ccache. Кстати, авторы CMake когда узнали о потребностях пользователей, начали судорожно искать подходы, предложили два (в том числе и symlinks). Но ответьте мне на простой вопрос. Почему в CMake возникают подобные проблемы, если все давно решено, все из покон веков используют ccache запросто, просто добавляя CC="/usr/bin/ccache /opt/toolchain/....../arm-linux-gnueabihf-gcc" и не извращаются. А авторы CMake напридумывали причин и занимаются анализом переменной CC, приводя ее в негодность!!!А плодить ссылки когда у вас toolchain-ов как у дурачка фантиков, - это абсурд.
Вам конечно виднее, но symlink-и придумали из-за того, что на тот момент воспринимать переменную CC как единое целое CMake уже не мог (слишком много переделывать в этом убогом проекте), вот и предложили затычку с линками.
Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не появлялись. От этого, конечно, не исчезает проблема, для решения которой они появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал бы такой проект.
Запомни, дружок: это называется неосиляторством.
Проблема cmake не для себя использовать, а то, что в отличие от тех же autotools каждый в своём проекте использует этот cmake по-другому, совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно что-то менять. А взять любой более менее известный проект на autotools - и сразу понятно, где что.
> Проблема cmake не для себя использовать, а то, что в отличие от
> тех же autotools каждый в своём проекте использует этот cmake по-другому,
> совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно
> что-то менять. А взять любой более менее известный проект на autotools
> - и сразу понятно, где что.Вы абсолютно правы. Проекты с autoconf, в основном, копируют друг друга и, если вдруг встречается ошибка в одном, другие тоже исправляются. А с CMake дело обстоит именно так как Вы говорите, кто в лес, кто по дрова. И чтобы поправить их косяки, сначала надо угадать, чтоже хотел автор, и что он не смог изучить для того, чтобы осуществить свои хотелки.
Вон, автотулзы были. Лучше бы вообще не было.
> Вон, автотулзы были. Лучше бы вообще не было.Однако новейшие проекты все-таки используют autoconf. Например, авторы Wayland не стали использовать CMake. Отсталые, наверное, и не понимают современных тенденций.
Андрей, а как вы считает gradle сможет заменить CMake? Там ведь тоже планируется поддерживать сборку С/С++ проектов.
> Андрей, а как вы считает gradle сможет заменить CMake? Там ведь тоже
> планируется поддерживать сборку С/С++ проектов.НЕТ. Он ничем не лучше Jam.
Вы знаете, если бы в MS Windows смогли обеспечить быструю работу препроцессоа GNU m4, то мало кому понадобились бы новые проекты. Особенно в этих новых проектах тяготит то, что авторы по-своему понимают архитектуру целевых устройств и записывают это понимание в собственные скрипты вместо того, чтобы просто передовать флаги компилятору. Я приведу пример из qtWebEngine (qt-5.7.0): для того, чтобы передать флаги компилятору вы присваиваете значение переменной QMAKE_CFLAGS, например QMAKE_CFLAGS="-march=armv7ve -mtune=cortex-a15". gyp_run.pro анализирует содержимое QMAKE_CFLAGS и создает собственные переменные, которые отдает очередному скрипту, написанному на языке подобном Json, который в свою очередь создает переменные, значения которых записывает в cflags для ninja файлов. В результате ваши флаги будут либо изменены, либо утеряны и кроме того, будут добавлены дополнительные флаги типа -mthumb, которые вам вовсе не нужны. Архитектура i386 вообще превратится в ia32. И так далее. Если же вы будете собирать под железо, о котором авторы WebEngine еще не знают, то вам придется либо патчить, либо ждать.И все это вместо того, чтобы просто передать CFLAGS компилятору!
В Jam, вам тоже придется переписывать ваши флаги в json, чтобы отдать их, например boost-у для сборки. И не факт, что он их поймет.
Словом. У новаторов слишком много времени и они не устают писать, писать и писать всякий бред.
> Вон, автотулзы были. Лучше бы вообще не было.Отнюдь. Для своего времени было неплохо, а сейчас есть тот же CMake. Со временем появится что-то еще лучше.
I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.
CMake активно поддерживается людьми, которые не хотят самостоятельно вызывать компилятор для сборки библиотек. То и они не хотят задавать разные управления в разных операционках, то ли вообще не догадываются о том, что в MS Windows есть команда cl.> Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не
> появлялись. От этого, конечно, не исчезает проблема, для решения которой они
> появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал
> бы такой проект.
Выход - сидеть и бухать. Если ты еще не видел, так делает большинство населения этой страны. Сидят по кухням и бухают. "Нам не нравятся некоторые проекты, которые активно развиваются. Мы бы хотели, что бы они никогда даже не появились", - говорят они. Только менее цензурно. "Надо было применить другой подход, я точно знаю какой. Я вообще специалист хоть куда, только меня недооценивают, и приходится бухать".
> "Надо было применить другой подход, я точно знаю какой.."Ты их ОЧЕНЬ СИЛЬНО переоцениваешь! За аналитикой синтетика у них не следует.
Обычно там всё ограничивается аналитикой (нытьём), упованиями "вот пришёл бы Ленин, Сталин, Галюк и сделал нам зашибись!" и, собственно, буханием/курением/принятием/употреблением.
Это аналитическое стадо даже смутно не представляет себе перспектив. У них просто должно быть "зашибись", "как раньше", "вот один умный мужик по телику говорил, но я не запомнил". О том, что надо самому во всём разобраться, поднять зад, что-то начать делать, проектировать, придумывать, синтезировать новое - стадо не догадается.
Единственное, что напрягает в cmake это верхний регистр символов.
Понятное дело, что можно писать в нижнем, но когда читаешь документацию или задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом терпимо.
Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
В Autotools больше возможностей, но осваивать его значительно труднее.
Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
В тоже время в cmake есть некоторые не очевидные вещи, которые трудно понять как настроить. Я бы сказал местами cmake не очевидный или немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
Начинать надо с простого:
https://www.gnu.org/software/pth/pth-manual.html#autoconf_bu...Сложное придет само:
https://www.gnu.org/software/hello/
>[оверквотинг удален]
> Понятное дело, что можно писать в нижнем, но когда читаешь документацию или
> задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом
> терпимо.
> Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
> В Autotools больше возможностей, но осваивать его значительно труднее.
> Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
> В тоже время в cmake есть некоторые не очевидные вещи, которые трудно
> понять как настроить. Я бы сказал местами cmake не очевидный или
> немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
> Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
>Единственное, что напрягает в cmake это верхний регистр символовТы воитину, крут! И терпелив! :)
>Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
Подскажите, на каких форумах можно найти народ хорошо разбирающийся в cmake?
> Подскажите, на каких форумах можно найти народ хорошо разбирающийся в cmake?Начните с https://ru.stackoverflow.com и https://stackoverflow.com