LINUX.ORG.RU

Вышел LLVM/Clang 3.9

 ,


3

7

Что нового в LLVM:

  • разработчики отказались от поддержки autoconf в пользу CMake;
  • добавлена совместимость с ABI для GCC версии 5 и выше;
  • добавлен анализатор MemorySSA, который работает быстрее и точнее, чем MemoryDependenceAnalysis.
  • добавлена поддержка ThinLTO через ключ -flto=thin — по сравнению с обычным LTO кодогенерация намного быстрее, а итоговый код производительнее;
  • теперь возможно использование ключа -march=skylake-avx512, активирующего поддержку соответствующих процессоров Intel.
  • теперь присутствует полноценная поддержка ARM-архитектур Qualcomm's Kryo и Broadcom's Vulcan, начальная поддержка Cortex-R8 и ARMv8.2-A.
  • для бэкенда AMDGPU реализованы шейдеры OpenGL, буферы, атомарные счётчики, шейдерные расширения.

Что нового в Clang:

  • все возможности OpenCL 2.0 полностью реализованы;
  • полностью реализован ОpenMP 4.5 для CPU, ведётся работа над GPU-частью;
  • начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z;
  • есть многочисленные изменения для ARM, MIPS и PowerPC.

>>> Подробности

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от EXL

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

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

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

invy ★★★★★ ()
Ответ на: комментарий от xaizek

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

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

invy ★★★★★ ()
Ответ на: комментарий от anonymous

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

rupert ★★★★ ()
Ответ на: комментарий от EXL

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

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

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от Deleted

Автотулз более нативен. 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(отличный язык для этих целей), но создали какой-то свой странный который трудно запомнить потому что нет стройной логики его создания.

tp_for_my_bunghole ()
Ответ на: комментарий от tp_for_my_bunghole

Для разработчика использующего 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 на винде — правильно прописать путь для поиска собранных модулей.

Stil ★★★★★ ()
Ответ на: комментарий от tp_for_my_bunghole

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

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

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

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

fluorite ★★★★★ ()
Ответ на: комментарий от fluorite

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

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

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

tp_for_my_bunghole ()
Ответ на: комментарий от anonymous

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

Исправил.

anonymous ()
Ответ на: комментарий от Stil

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

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

ananas ★★★★★ ()
Ответ на: комментарий от invy

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от invy

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

AlexM ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от Deleted

BSD

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

AlexM ★★★★★ ()
Ответ на: комментарий от EXL

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

pftBest ★★★★ ()
Ответ на: комментарий от tp_for_my_bunghole

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

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

pftBest ★★★★ ()
Ответ на: комментарий от invy

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

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

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

xaizek ★★★★★ ()
Ответ на: комментарий от pftBest

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

xaizek ★★★★★ ()
Ответ на: комментарий от AlexM

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

Deleted ()
Ответ на: комментарий от pftBest

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

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

ananas ★★★★★ ()
Ответ на: комментарий от ananas

два. configure.ac и makefile.am

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

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

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

pftBest ★★★★ ()
Ответ на: комментарий от pftBest

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

xaizek ★★★★★ ()
Ответ на: комментарий от ananas

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от AlexM

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

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

ananas ★★★★★ ()
Ответ на: комментарий от ananas

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

ananas ★★★★★ ()
Ответ на: комментарий от ananas

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

ananas ★★★★★ ()
Ответ на: комментарий от intelfx

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

  • вменяемый синтаксис (да, я серьёзно так считаю. возможно, он уродливый, но хотя бы не 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

KennyMinigun ★★★★★ ()
Ответ на: комментарий от ananas

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

anonymous ()
Ответ на: комментарий от KennyMinigun

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

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

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

WatchCat ★★★★★ ()

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

Chaser_Andrey ★★★★★ ()
Ответ на: комментарий от ananas

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

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

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

anonymous ()
Ответ на: комментарий от Chaser_Andrey

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

anonymous ()
Ответ на: комментарий от pftBest

Посчитай сколько файлов тебе нужно создать чтобы собрать простой проект. Для 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 есть хорошие свойства, но для закрытых проектов. Стандарта нет. Как настраивать сборку обычно знают только разработчики.

tp_for_my_bunghole ()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 2)

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

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

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

anonymous ()
Ответ на: комментарий от KennyMinigun

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

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

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

Верно.

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от xaizek

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

invy ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.