Вышел LLVM/Clang 3.9

• вменяемый синтаксис (да, я серьёзно так считаю. возможно, он уродливый, но хотя бы не write-only);
• прекрасная документация;
• export compile commands;
• адекватная поддержка кросс-компиляции (можно взять любой проект, написать тулчейн-файл из пяти строк, задать sysroot и/или префикс и быть почти уверенным, что оно корректно соберётся);
• при прямых руках — возможность использовать одну и ту же сборочную систему для сборки «под упаковку» и для сборки «как подпроект»;
• inter-project transitive dependencies без каких-либо телодвижений.

Это только то, что вспомнилось сразу (на основании того, что я сейчас делаю).

Почему ты пытаешься извернуться?

Не переводи стрелки, это ты приплел сюда берд про оффтопик.

А мне пофиг. CMake делает свое дело и в большинстве случаев делает его хорошо и код мэйкфайлов относительно адекватен, что еще надо.

Variable names are case-sensitive and may consist of almost any text
Command names are case-insensitive.

Нравится писать маленькими - пиши маленькими, нравится большими - пиши большими, в чем проблема? :) Или сложно выбрать что-то одно?

Нравится писать маленькими - пиши маленькими, нравится большими - пиши большими, в чем проблема? :)

http://risovach.ru/upload/2014/12/mem/i-tak-soydet_69529414_orig_.jpg

https://github.com/yasm/yasm-nextgen/blob/master/CMakeLists.txt

IF if SET set ENDIF endif

Типичная реакция столлманутого.

Когда он уже коньки отбросит от своего обжорства.

человек в этом видео

где-то я уже похожее видел... вот:
Яр - очередное сочинение на тему синтаксиса

den73

Печально, что на http://llvm.org/releases/download.html#3.9.0 перестали собирать бинарники для CentOS.

Тебе шашечки или ехать?

На автотулс посмотри тогда.

Автотулз более нативен. Cmake генерирует проекты под IDE.

Autotools это стандарт. Более удобен для пользователя чем CMake.

./configure --help

И всё ясно:

--disable-FEATURE
--enable-FEATURE[=ARG]
Some influential environment variables:
...

Это GNU Coding Standards, в который входит Standard Targets for Users:

make install
make uninstall
make install DESTDIR=~/mydir #staged install
make dist
make clean
make distclean

и другие.

Netbeans создаёт проект на основе Makefile, значит этого достаточно.

Для разработчика использующего autotools тоже всё просто.

В windows достаточно среды MinGW. Все утилиты которые могут вызываться в Makefile сгенерированным automake: awk cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true.

С точки зрения кроссплатформенности в любой системе для сборки достаточно posix shell, make, cc/c++, и этих утилит.

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

Как я понял, компания которая начала разработку CMake, использовала в своем продукте TCL(отличный язык для этих целей), но создали какой-то свой странный который трудно запомнить потому что нет стройной логики его создания.

Для разработчика использующего autotools тоже всё просто.

А как вы кросс-компилируете util-linux?

Почему autotools при кросс-компиляции пытается подхватить библиотеки с хостовой системы?

--

Autotools or qmake? (комментарий) :)

В windows достаточно среды MinGW. Все утилиты которые могут вызываться в Makefile сгенерированным automake: awk cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true.

Угу, а cmake она не нужна. И тулзы не нужны. И тулчейн божет быть MSVC'шный.

Пробовал собирать на винде проект с ворохом разных зависимостей типа Qt, ffmpeg и poppler? Я пробовал. Btw, всё что нужно сделать с cmake на винде — правильно прописать путь для поиска собранных модулей.

Netbeans создаёт проект на основе Makefile, значит этого достаточно.

Для разработчика использующего autotools тоже всё просто.

В windows достаточно среды MinGW.

Нефть никогда не будет ниже 80$ за баррель. Недвижимость всегда растёт. Земля плоская.

Нефть никогда не будет ниже 80$ за баррель. Недвижимость всегда растёт. Земля плоская.

C++ никогда не умрёт. Продолжительность компиляции/сборки не имеет значения.

http://yosefk.com/c fqa/defective.html

Наша свобода свободистей чем ваша, потому-что мы запрещаем злоупотреблять свободой.

Исправил.

Пробовал собирать на винде проект с ворохом разных зависимостей типа Qt, ffmpeg и poppler?

а зачем их собирать под виндой?

Нет, в условиях реального зоопарка. Операционок с либсями, компиляторов, прочих тулзов.

Это сейчас из *никсов, почитай, никого в живых не осталось, а те, что остались — более-менее гомогенизировались по пользовательскому окружению.

Уныло: ну, я пробовал.

Их больше было. У нас в пределах одной комнаты в Автоматике стояло три (или четыре?) аппаратных платформы, и в каждой избушке — свои погремушки.

гарантированно был только шелл.

Да и тот, «с особенностями» (см. стандартный набор начальных тестов).

BSD

В 95-ом году оно уже расфоркалось на пяток, наверное, вариаций.

Левый диск ты можешь отформатировать, но систему на него поставить тебе не разрешат.

Для разработчика использующего autotools тоже всё просто.

Посчитай сколько файлов тебе нужно создать чтобы собрать простой проект. Для cmake только 1.

Нравится писать маленькими - пиши маленькими, нравится большими - пиши большими, в чем проблема? :) Или сложно выбрать что-то одно?

Если бы там были нормальные сообщения об ошибках, а не нечитаемые простыны (ошибки от Boost.Spirit понятнее в большинстве случаев...), то может оно и ничего. А так правишь и офигеваешь, что в одном месте правила одни, в другом другие оказываются. По сравнению с этим, autotools это образец постедовательности и цельного дизайна.

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

Если не считать пустые файлы (на необходимость которых будет указано), то для autotools тоже один. Как-то так.

Ага, я не стал об этом упоминать, чтобы не провоцировать спор о том, насколько эти вариации были отличны друг от друга.

Посчитай сколько файлов тебе нужно создать чтобы собрать простой проект. Для cmake только 1.

для autotools - всего два. вот только для сборки cmake-проекта требуется еще и cmake в системе, а для сборки autotools-проекта - только posix shell. продолжаем мериться дальше?

autotools тоже один

два. configure.ac и makefile.am

два. configure.ac и makefile.am

Там же было о простом проекте и я показал, как сгенерировать configure.ac с помощью autoscan, т.е. писать его руками не надо было (только инициализацию automake потом добавить).

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

сгенерированный зачастую требует правки

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

а для сборки autotools-проекта - только posix shell.

... и, ЕМНИП, набор утилит (в нынешнем линуксе — coreutils).

и, ЕМНИП, набор утилит (в нынешнем линуксе — coreutils).

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

Что не мешает крупным дистрам не устанавливать эти пакеты по-умолчанию

Что не мешает крупным дистрам не устанавливать эти пакеты по-умолчанию

??? ты вообще о чем? эти - это какие?

эти - это какие?

Например make, например gcc, без этого и не соберешь autotools проект на такой «базовой» системе

Например make, например gcc, без этого и не соберешь autotools проект на такой «базовой» системе

любитель все довести до абсурда?

Захотелось влезть в вашу беседу. По моему опыту хочу добавить/опротестовать завления:

• вменяемый синтаксис (да, я серьёзно так считаю. возможно, он уродливый, но хотя бы не write-only);
  • Вот только каждый раз после перерыва колупания в CMake, доводится лезть в документацию чтоб написать хоть что-либо. Субьективно, я бы не против чтоб он имел биндинги к какому-нибудь мейнстримовому скрипт-язычку: JS (node, etc), Perl, Python да хоть Lua.
  • Когда доходит до написания сценария сборки с тем, для чего у CMake нет встроенных функций, CMakeLists.txt начинают обрастать уродливыми конструкциями
• при прямых руках — возможность использовать одну и ту же сборочную систему для сборки «под упаковку» и для сборки «как подпроект»;
  • Ну уж нет. Прямоту рук незачем тут подвязывать. Мучений больше чем результата. Даже самый «передовой» CPackRPM имеет ряд багов/wontfix (например непредсказуемо добавляет %config к файлам которые были install(FILES ...)). Да и он не поддерживает всех возможностей RPM-а (%shadow, например). По єтому куда проще завернуть CMake в систему сборки пакетов, а не наоборот

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

P.S. У меня сейчас появилась возможность поколупать scons в продакшене. Может позже буду хейтить CMake даже :D

Любитель указать на бред «искаропке» когда речь идёт о сборке и ты один хрен не один ворох говна ещё поставишь.

CMakeLists.txt начинают обрастать уродливыми конструкциями

Да выучи наконец макросы и модули в CMake.

Так-то и в плюсах можно городить проект в одном файле, но нахрена?

Пока не поменяют лицензию на GPLv3+ - буду использовать и лоббировать только gcc. Во имя FreeSoftware.

для autotools - всего два. вот только для сборки cmake-проекта требуется еще и cmake в системе, а для сборки autotools-проекта - только posix shell. продолжаем мериться дальше?

Я пишу на Компонентном Паскале и читая проблемы со сборкой проектов мне становится смищно. А со мной мерится не надо, так как я весь модульный и компонентный. Ещё, я не знаю, что такое система сборки cmake и autotools. Ибо вся эта ваша хуита сборочная система по сравнению со средой BlackBox CB каменный век.

Си плюс-плюснутые лохи страдайте дальше.

шоман украл твой аватар. Подай на него протест.

Посчитай сколько файлов тебе нужно создать чтобы собрать простой проект. Для cmake только 1.

Для autotools 2, configure.ac и Makefile.ac;

configure.ac:

AC_INIT([Tutorial Program], 1.0)
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CONFIG_FILES(Makefile)
AC_OUTPUT

Makefile.ac:

bin_PROGRAMS = prog_name			
prog_name_SOURCES = main.c

Комманды:

> aclocal
> autoconf
> automake --add-missing --foreign

Если это сложно для разработчика который должен писать программы на C++, то надо остановиться и подумать что вообще делать. Простые принципы текстовых макро. Libtool требует чтения как и git в начале.

CMake не представляет почти никакой контекстной помощи в командной строке проекта. Какой-то мусор показывает. Но во время сборки красивенько, цвета.

У CMake есть хорошие свойства, но для закрытых проектов. Стандарта нет. Как настраивать сборку обычно знают только разработчики.

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

Тем же занимаюсь, впечатления обратные.

Раз вы такие крупные специалисты, помогите человеку Использование autotools в больших древовидных проектах

бозя накажет

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

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

Субьективно, я бы не против чтоб он имел биндинги к какому-нибудь мейнстримовому скрипт-язычку: JS (node, etc), Perl, Python да хоть Lua.

Верно.

Ну уж нет. Прямоту рук незачем тут подвязывать. Мучений больше чем результата. Даже самый «передовой» CPackRPM имеет ряд багов/wontfix (например непредсказуемо добавляет %config к файлам которые были install(FILES ...)). Да и он не поддерживает всех возможностей RPM-а (%shadow, например). По єтому куда проще завернуть CMake в систему сборки пакетов, а не наоборот

Я не говорю сейчас про взаимодействие с пакетным менеджером (зачем оно?). Речь шла о том, что если писать идиоматично, то одно и то же дерево исходников можно использовать и для cmake . && make install + find_package(), и для add_subdirectory(). И это удобно.

А out of tree build этот ваш автотулс уже научился?