The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск системы сборки CMake 3.6

07.07.2016 21:05

Состоялся релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.6, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD.

CMake примечателен предоставлением простого языка сценариев, средствами расширения функциональности через модули, минимальным числом зависимостей (нет привязки к M4, Perl или Python), поддержкой кэширования, наличием инструментов для кросс-компиляции, поддержкой генерации файлов сборки для широкого спектра систем сборки и компиляторов, наличием утилит ctest и cpack для определения сценариев тестирования и сборки пакетов, утилитой cmake-gui для интерактивной настройки параметров сборки.

Основные улучшения:

  • В генератор файлов сборки для 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.


  1. Главная ссылка к новости (https://blog.kitware.com/cmake...)
  2. OpenNews: Выпуск системы сборки CMake 3.5
  3. OpenNews: Разработчики из компании Google открыли код системы сборки Ninja
  4. OpenNews: Компания Google представила первый выпуск открытой системы сборки Bazel
  5. OpenNews: Twitter представил первый значительный выпуск системы сборки Pants
  6. OpenNews: Выпуск системы сборки GNU Make 4.2
Лицензия: CC-BY
Тип: Программы
Ключевые слова: cmake, make
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ANDREY KOSTELTSEV (?), 23:52, 07/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А авторы хотябы в этом релизе догадались, что такое --libdir, --bindir, --sbindir ли может хотябы разобрались в отличиях --prefix и DESTDIR ?
     
     
  • 2.3, BlackRaven86 (ok), 00:00, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Сто лет уже как есть https://cmake.org/cmake/help/v3.6/module/GNUInstallDirs.html
     
     
  • 3.8, ANDREY KOSTELTSEV (?), 00:39, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных приводит к нужному результату.
     
     
  • 4.14, BlackRaven86 (ok), 01:36, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
    > приводит к нужному результату.

    Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.

     
     
  • 5.17, ANDREY KOSTELTSEV (?), 01:42, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Покажите мне хотябы один проект, использующий CMake в котором задание этих переменных
    >> приводит к нужному результату.
    > Любой проект, который использует GNUInstallDirs. У меня такие есть и все работает.

    Вы наверное их делаете сами. Вы назовите конкретный пакет.
    Ведь ни один из перечисленных в новости такими свойствами не обладает.
    Словом, назовите конкретный пакет, я посмотрю как он сделан.


     
     
  • 6.22, Аноним (-), 05:45, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Подтверждаю. Это работает везде. Это у вас самого проблемы на вашем локалхосте, разбирайтесь со своими настройками, почему у вас это нигде не работает.
    Говорят же вам люди - работает.
     
  • 6.37, BlackRaven86 (ok), 14:22, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Например: https://github.com/search?l=cmake&q=include%28GNUInstallDirs%29&ref=
     
  • 4.24, Ilya Indigo (ok), 07:50, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    eiskaltdcpp-qt подойдёт? А так куча других могу привести.
    [code]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[/code]

    А вот в проектах БЕЗ cmake, приходится вот так вот извращаться.
    [code]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[/code]

     
     
  • 5.27, anonymous (??), 08:45, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > vim Makefile

    make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5

    не кактит, да?

     
     
  • 6.29, Аноним (-), 09:09, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    У человека просто cmake головного мозга, или по простому каша в голове.
     
  • 6.30, Ilya Indigo (ok), 09:36, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> vim Makefile
    > make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
    > не кактит, да?

    Нет, не катит. PREFIX не изменяется.

     
     
  • 7.34, ANDREY KOSTELTSEV (?), 10:37, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>> vim Makefile
    >> make -j4 PREFIX=/usr QMAKE=qmake-qt5 LRELEASE=lrelease-qt5
    >> не кактит, да?
    > Нет, не катит. PREFIX не изменяется.

    Разумеется, что такое переменные окружения, авторы CMake сначала тоже не знали, все через текстовый файл. Новая целевая архитектура? - готовь новый файл -DCMAKE_TOOLCHAIN_FILE=path/to/file

     
     
  • 8.41, dhamp (?), 16:24, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Авторы СMake дали возможность читать ENV переменные, то что это большинство не и... текст свёрнут, показать
     
  • 7.45, anonymous (??), 08:58, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > >> 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 = internal

    dummy:
    echo ${PREFIX}
    $

     
  • 5.33, ANDREY KOSTELTSEV (?), 10:32, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не подойдет, в нем QUI с использованием qmake собирается. А Qmake, как я говорил ранее, гораздо лучше чем CMake. Там люди понимали что творят. Лучше вы посмотрите на проект, который необходим для Qt-3d https://github.com/assimp/assimp.

     
     
  • 6.38, BlackRaven86 (ok), 14:24, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А Qmake, как я говорил ранее, гораздо лучше чем CMake. Там люди понимали что творят.

    Толсто.

     
  • 6.40, dhamp (?), 16:11, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Не подойдет, в нем QUI с использованием qmake собирается.

    В eiskaltdcpp Qt UI собирается с помощью qmake? Видать я, как один из авторов, не в курсе.... вот же не задача.

     
  • 6.43, rico (ok), 19:08, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил и CMake. И про qmake ты говоришь вещи, которые для видевшего этот ад и израиль давно не новость.
     
     
  • 7.47, ANDREY KOSTELTSEV (?), 17:36, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Андрюша, ну тебя сегодня утерли в треде. И гугл ты не осилил
    > и CMake. И про qmake ты говоришь вещи, которые для видевшего
    > этот ад и израиль давно не новость.

    Люди просто не собирали чужие пакеты в таких количествах кросс-компиляторами для разных целевых систем. Работая на PC и для PC косяки не видны и мир гораздо проще. А на счет "утерли", если от этого их самолюбие станет больше, так я только рад за них.

     
     
  • 8.49, rico (ok), 20:42, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Несомненно, на non PC переменные окружения видимо по-другому окружают ... текст свёрнут, показать
     

  • 1.2, ANDREY KOSTELTSEV (?), 23:56, 07/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Несчастные пользователи CMake вынуждены добавлять собственные переменные типа LLVM_LIBDIR_SUFFIX или ASSIMP_LIB_INSTALL_DIR.

    И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?

     
     
  • 2.23, andy (??), 06:13, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Почему Вы эти вопросы задаете на opennet.ru, а не
    в багтрекере проекта?
     
     
  • 3.31, ANDREY KOSTELTSEV (?), 09:46, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Задаю, разумеется, и в проектах. Баги завожу. Только проблема в том, что ошибки в проектах делятся на те, которые обусловлены самим фактом использования CMake и те, которые допускают авторы проекта. А здесь я, фактически не задаю вопросы, а констатирую факты в надежде, что хоть кто-нибудь начиная собственный проект, задумается о выборе средств.

     
  • 2.42, dhamp (?), 16:25, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И еще вопрос. Когда наконец CMake начнет правильно понимать CCACHE(1)?

    И в чём же он не правильно его понимает?

     
     
  • 3.46, ANDREY KOSTELTSEV (?), 17:25, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    http://stackoverflow.com/questions/1815688/how-to-use-ccache-with-cmake
     
     
  • 4.48, dhamp (?), 18:24, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Описания по ссылке проблем CMake как ни странно нет, а вот у людей желания использовать его не согласно документации хоть отбавляй, но виноват как всегда кто-то другой.
     
     
  • 5.50, ANDREY KOSTELTSEV (?), 23:18, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вот вам пример. Для того чтобы использовать 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-faster-compilation/

    Авторы, использующие CMake этого, практически никогда не делают.

    Между тем, для нормальных систем, чтобы использовать CCACHE достаточно задать переменную
    CC="/usr/bin/ccache gcc". Однако CMAKE прочитав значение переменной CC начнет делать предположения. И получится, что в качестве компилятора CMake выберет "/usr/bin/ccache", а "gcc" - сочтет первым аргументом.

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

     
     
  • 6.51, dhamp (?), 17:31, 10/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Видимо я всегда делал что-то не так, если мне нужен был 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 его уже не сделал), это же столько лишних действий.....

     
     
  • 7.52, ANDREY KOSTELTSEV (?), 02:20, 11/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы молодец конечно. Символические ссылки - это один из способов использовать ccache. Кстати, авторы CMake когда узнали о потребностях пользователей, начали судорожно искать подходы, предложили два (в том числе и symlinks). Но ответьте мне на простой вопрос. Почему в CMake возникают подобные проблемы, если все давно решено, все из покон веков используют ccache запросто, просто добавляя CC="/usr/bin/ccache /opt/toolchain/....../arm-linux-gnueabihf-gcc" и не извращаются. А авторы CMake напридумывали причин и занимаются анализом переменной CC, приводя ее в негодность!!!

    А плодить ссылки когда у вас toolchain-ов как у дурачка фантиков, - это абсурд.

    Вам конечно виднее, но symlink-и придумали из-за того, что на тот момент воспринимать переменную CC как единое целое CMake уже не мог (слишком много переделывать в этом убогом проекте), вот и предложили затычку с линками.

     

  • 1.4, Андрей (??), 00:08, 08/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не появлялись. От этого, конечно, не исчезает проблема, для решения которой они появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал бы такой проект.
     
     
  • 2.6, Аноним (-), 00:37, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Запомни, дружок: это называется неосиляторством.
     
     
  • 3.28, Андрей (??), 08:52, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема cmake не для себя использовать, а то, что в отличие от тех же autotools каждый в своём проекте использует этот cmake по-другому, совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно что-то менять. А взять любой более менее известный проект на autotools - и сразу понятно, где что.
     
     
  • 4.32, ANDREY KOSTELTSEV (?), 09:51, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема cmake не для себя использовать, а то, что в отличие от
    > тех же autotools каждый в своём проекте использует этот cmake по-другому,
    > совсем без каких-то устоявшихся шаблонов, и очень сложно разобраться, когда нужно
    > что-то менять. А взять любой более менее известный проект на autotools
    > - и сразу понятно, где что.

    Вы абсолютно правы. Проекты с autoconf, в основном, копируют друг друга и, если вдруг встречается ошибка в одном, другие тоже исправляются. А с CMake дело обстоит именно так как Вы говорите, кто в лес, кто по дрова. И чтобы поправить их косяки, сначала надо угадать, чтоже хотел автор, и что он не смог изучить для того, чтобы осуществить свои хотелки.

     
  • 2.7, Аноним (-), 00:38, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вон, автотулзы были. Лучше бы вообще не было.
     
     
  • 3.12, ANDREY KOSTELTSEV (?), 01:04, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вон, автотулзы были. Лучше бы вообще не было.

    Однако новейшие проекты все-таки используют autoconf. Например, авторы Wayland не стали использовать CMake. Отсталые, наверное, и не понимают современных тенденций.

     
     
  • 4.44, Guest (??), 01:52, 09/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Андрей, а как вы считает gradle сможет заменить CMake? Там ведь тоже планируется поддерживать сборку С/С++ проектов.
     
     
  • 5.53, ANDREY KOSTELTSEV (?), 02:43, 11/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Андрей, а как вы считает 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-у для сборки. И не факт, что он их поймет.

    Словом. У новаторов слишком много времени и они не устают писать, писать и писать всякий бред.

     
  • 3.15, BlackRaven86 (ok), 01:38, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Вон, автотулзы были. Лучше бы вообще не было.

    Отнюдь. Для своего времени было неплохо, а сейчас есть тот же CMake. Со временем появится что-то еще лучше.

     
  • 3.36, Аноним (-), 13:40, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    I saw a book entitled "Die GNU Autotools" and I thought "My feelings exactly". Turns out the book was in German.
     
  • 2.10, ANDREY KOSTELTSEV (?), 00:52, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/

    CMake активно поддерживается людьми, которые не хотят самостоятельно вызывать компилятор для сборки библиотек. То и они не хотят задавать разные управления в разных операционках, то ли вообще не догадываются о том, что в MS Windows есть команда cl.

    > Вот есть некоторые активно развиваемые проекты, которые мне бы хотелось, чтобы не
    > появлялись. От этого, конечно, не исчезает проблема, для решения которой они
    > появляются. Но хотелось бы, чтобы кто-то другой с другим подходом создал
    > бы такой проект.

     
  • 2.25, АнонимХ (ok), 07:55, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Выход - сидеть и бухать. Если ты еще не видел, так делает большинство населения этой страны. Сидят по кухням и бухают. "Нам не нравятся некоторые проекты, которые активно развиваются. Мы бы хотели, что бы они никогда даже не появились", - говорят они. Только менее цензурно. "Надо было применить другой подход, я точно знаю какой. Я вообще специалист хоть куда, только меня недооценивают, и приходится бухать".

     
     
  • 3.26, robux (ok), 08:21, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > "Надо было применить другой подход, я точно знаю какой.."

    Ты их ОЧЕНЬ СИЛЬНО переоцениваешь! За аналитикой синтетика у них не следует.

    Обычно там всё ограничивается аналитикой (нытьём), упованиями "вот пришёл бы Ленин, Сталин, Галюк и сделал нам зашибись!" и, собственно, буханием/курением/принятием/употреблением.

    Это аналитическое стадо даже смутно не представляет себе перспектив. У них просто должно быть "зашибись", "как раньше", "вот один умный мужик по телику говорил, но я не запомнил". О том, что надо самому во всём разобраться, поднять зад, что-то начать делать, проектировать, придумывать, синтезировать новое - стадо не догадается.

     

  • 1.5, vitalikp (?), 00:37, 08/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Единственное, что напрягает в cmake это верхний регистр символов.
    Понятное дело, что можно писать в нижнем, но когда читаешь документацию или задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом терпимо.
    Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
    В Autotools больше возможностей, но осваивать его значительно труднее.
    Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
    В тоже время в cmake есть некоторые не очевидные вещи, которые трудно понять как настроить. Я бы сказал местами cmake не очевидный или немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
    Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.
     
     
  • 2.9, ANDREY KOSTELTSEV (?), 00:48, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Начинать надо с простого:
    https://www.gnu.org/software/pth/pth-manual.html#autoconf_build_environment__a

    Сложное придет само:
    https://www.gnu.org/software/hello/


    >[оверквотинг удален]
    > Понятное дело, что можно писать в нижнем, но когда читаешь документацию или
    > задаешь параметры сборки(или еще что-нибудь) это немного отвлекает. Хотя в целом
    > терпимо.
    > Если сравнивать с Autotools, то разобраться с нуля конечно легче на cmake.
    > В Autotools больше возможностей, но осваивать его значительно труднее.
    > Даже написать простенький конфиг не подсматривая на другой проект будет довольно сложно.
    > В тоже время в cmake есть некоторые не очевидные вещи, которые трудно
    > понять как настроить. Я бы сказал местами cmake не очевидный или
    > немного заумный. В детали не хочу вдаваться, но кто пользуется поймет.
    > Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.

     
  • 2.39, glebiao (ok), 14:53, 08/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >Единственное, что напрягает в cmake это верхний регистр символов

    Ты воитину, крут! И терпелив! :)

    >Хочется некоторой простоты, которой нету ни в cmake, ни в Autotools.

    http://scons.org

     

  • 1.54, Алексей (??), 13:12, 02/01/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите, на каких форумах можно найти народ хорошо разбирающийся в cmake?
     
     
  • 2.55, Ilya Indigo (ok), 16:12, 03/01/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Подскажите, на каких форумах можно найти народ хорошо разбирающийся в cmake?

    Начните с https://ru.stackoverflow.com и https://stackoverflow.com

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру