CMake 3.28

Сложность поддержки трех проектов, как я уже писал, сильно преувеличена адептами CMake

Так можно что угодно оправдать: сложность сопровождения дублированного в трех местах кода сильно преувеличена адептами вынесения общего кода в отдельные функции.

Для многих намного удобнее сделать это два/три раза в IDE, чем вбивать списки файлов руками в CMake скрипте

Печатаешь руками, а кликаешь/перетаскиваешь чем? Ногами?

Для выполнения специальных действий в гуевых настройках есть всякие Pre/Post Build Events. Опять же, не составляет особых проблем забить туда нужные команды на поверщели или баше

Мда, в винде bat/ps пишешь, в linux/mac тоже самое повторяешь на bash. Лепота.

Тем паче, что многие ассеты типа иконок и ресурсов изначально платформозависимы

А одинаковые ассеты указываем в трех местах.

В CMake скриптах ты же как-то привык набивать if/else/endif

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

Норм доки - это например Qt или MSDN. А CMake - это все что угодно, только не нормальные доки. Хуже этих доков может быть разве что их отсутствие.

Вполне удобные и подробные. Давай так: что ты в них не нашел?

В проприетарной разработке ты как правило будешь писать на том, на чем тебе скажут

Если проект писали адепты «я начальник, вы идиоты», то да, так и будет. Если адекватные люди, то они сделают возможность работы с теми инструментами, которые удобнее для девелоперов.

Популярность CLion и Qt Creator можно приблизительно оценить по ежегодному опросу StackOverflow

А это вообще не важно. Это из оперы «все сидят на винде, и вы тоже будете». Хороший начальник не будет замыкаться на чем-то одном. А кто так делает скорее всего просто заржавел и не хочет что-то лучшее учить.

И хаотичные метания с MSVS на Ninja и обратно скорее всего не поприветствуют. «Миша, у тебя скучное лицо, тебе никто денег не даст» (c).

Это вообще сравнение соленого с красным. MSVC - компилятор, Ninja - система сборки, типа make. Если она можеть дать +20% к скорости сборки - это отличная возможность сделать билд сервер чуть более быстрым. А если все гвоздями сделано на VS, то хер с два.

В проприетарной разработке вообще очень часто сборка намертво захардкожена

Ну и. Это не значит, что это хорошо. Часто так происходит, потому что писать начали давно, как умели и теперь тянут кучу костылей и либ бородатых версий. В одной такой конторе мне на голубом глазу объясняли сборку на VS: первый раз сборка скорее всего завершится ошибкой, потому что там что… а со второго раза должно все собраться.

Зависимости кладутся в папочку 3rdparty и пути к ним хардкодятся в проекте, без всякого там поиска системных библиотек. Никто не будет тратить деньги и время разработчиков/тестировщиков на супер-пупер конфигурируемую сборку, позволяющую на лету менять компиляторы и библиотеки. И вот в таких условиях гибкость и расширяемость CMake оказывается по большей части бесполезной. Возникает вопрос - а не проще ли вместо CMake тупо использовать раздельные проекты Visual Studio и Xcode, идеально заточенные именно под проприетарную разработку?

Это все про легаси проекты с лидами, которые уже все забыть успели и ничего не хотят делать. А только выдумавают: «ну это же проприетарщина, тут мы все прибиваем гвоздями и перетаскиваем мышью.»

Только вот всратый CMake - это пожалуй один из худших вариантов для написания подобных скриптов. Хуже разве что автотулзы, хотя CMake в общем-то недалеко от них ушел. Как я уже раньше писал, намного лучше было бы писать скрипты сборки на самих крестах.

CMake точно не идеален со своим одним строковым типом. Но по уровню всратости VS и Xcode далеко вперед ускакали. Как я уже написал, в своей нише универсального средства/формата описания проекта и его сборки ничего лучше cmake не придумали.

На опеннете только проснулись. Молодец я! :)

По личному опыту в десктопной разработке этот подход ВНЕЗАПНО неплохо работал

Три раза один код копипастить тоже будет неплохо работать. Только удобства никокого.

Основным и эталонным проектом обычно считался студийный. Именно он пилился и тестировался в первую очередь.

Ну а вот у нас win/mac - основные таргет системы, Linux - уже по остаточному. И собираются/тестируются постоянно. Если ты предлагаешь при добавлении нового файла исходников каждый раз в трех местах править - спасибо, я лучше как нибудь на cmake в одном месте сделаю.

Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным. Чаще всего этим занимался отдельный разработчик, так что виндузне не требовалось заводить виртуалки и разбираться в никсах. Обычно вся синхронизация сводилась к добавлению недостающих файлов в Mac/Linux проекты, реже к мелким правкам компиляции, натыкиванию #ifdef и дописыванию платформо-зависимых частей.

Вместо того, чтобы один раз во время разработки таски весь код, который к ней относиться, проверить на собираемость и проверить тестировщиком на всех системах, делаем это только для винды. Потом через три недели отвлекаем разработчика от текущих дел и заставляем заниматься этой таской, и другими по той же причине, которые не факт что он делал и вносим дополнительные изменения в исходники. Ой красота какая. А доп тестирование делаем? А исходная таска уже вмержена? У вас, я посмотрю, все круто поставлено. Хотя просто у вас mac/lin не в приоритете, или даже в принципе пофиг на эти системы.

Именно. Как только объем CMake скриптов переваливает определенный порог, поддерживать их становится очень невесело

Кроссплатформенный CMake такой кроссплатформенный.

Нормально их поддерживать. Если писать нормально.

Android, iOS

Это другая история. Там cmake не самодостаточен. Но я обратного не утверждал.

https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?v... CMake projects in Visual Studio

На habr блог есть об использовании Visual Studio для сборки под Linux.
...

Появится необходимость, буду разбираться.

Ну, то есть, все проблемы из-за того, что кто-то ССЗБ и запилил что-то, завязав это на MSVC

В идеале крестам нужно что-то наподобие Cargo

Вспомнил про https://build2.org и их https://cppget.org.

Вообще сама идея использовать отдельный язык чисто для сборки крестопроектов изначально ущербна.

Но да, у build2 этот же путь. :)

«Бульба (исходники) ёсть, вода (Perl) радом. Пишем скрипт сборки на Perl и парадок».

Можно придумать какой-нибудь формат xml (или использовать уже готовый, например xml, содержащий проект для Visual Studio), содержащий метаданные для сборки.
Затем запускаем генератор, который, используя данные xml, создаёт сборочный скрипт (например на Perl).

содержащий метаданные для сборки.

Только под винду?

Затем запускаем генератор, который, используя данные xml, создаёт сборочный скрипт (например на Perl).

А кто бы это сделал? И не будет ли это сильно медленно по итогу собирать.

cmake предлагает проштудировать и юзать эту портянку.

Во-первых да. Надо читать документацию к такому мощному инструменту, если хочешь его использовать на профессиональном уровне. RTFM никто не отменял.

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

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

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

И да, у него есть прекрасная обёртка для pkg-config, если всё остальное не работает.

Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным.

А про CI/CD слыхали?

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

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

А главное - это его родовые травмы, он костылём был, костылём живёт, костылём и помрёт генеря мусор для вазелиновых студий. Цели у проекта должны быть годными. Компиль напрямую вызывать, а не встравиваться костылём; Не искать либы на всяких дырявых осях типа венды во всех щелях и устанавливать тоже черт пойми куда, а признавать только UNIX like организацию диска, создавать в винде соответствующее дерево директорий в корне и кидать всё туда. Плюс какой-то демон для венды, который будет следить за установкой необходимыми переменными окружения (HOME, например).

Вот если бы так дела обстояли, то другой бы разговор был. При некоторой критической массе проектов, которые юзают такой правильнй cmake, венде бы пришлось признать реальность и сделать себя UNIX like. А так - ущербная поделка-костыль, да ещё и с ужасным DSL, лучше уж мезоном. Если по сути разницы нету, то зачем блевать от cmake’а?

Эталонный бред.

А кто бы это сделал?

Кто не поленится, тот и сделает.
Сложность решения этой задачи лишь одна - лень.

скриптопараши в движке O3DE

Мда… полистал это убожество. У меня ещё примеры были не такие адовые. Им следовало выкинуть нах этот кривой и убогий CMake и взять Waf, как сделали немцы из CryTek со своей огромной плюсовой базой: https://docs.cryengine.com/display/SDKDOC4/WAF+Build+System

Тогда бы они сразу писали на Python’е все свои сложные сборочки скрипты и конфигураторы без этой упоротой CMake-дрисни.

Тогда бы они сразу писали на Python’е все свои сложные сборочки скрипты и конфигураторы без этой упоротой CMake-дрисни.

И получили бы портянки с питоньей дриснёй, ибо упоротость разработчиков никуда бы не делась.

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

Вперед, я на это посмотрю.

взять Waf

Он сам собирает? Или вызывает нижележащую систему сборки?

сделай так чтобы это работало под виндой

А это кстати очень просто делается.

1. Выкидывается штудия вместе с тем хламом на 10 GB который нужно поставить ради того чтобы скомпилить main() {return 0;}

2. Ставится MSYS2: https://www.msys2.org/ в котором есть pkgconfig и прочие удобнейшие UNIX-тулзы.

это все работает (и то не факт, сильно подозреваю что у всех этих MSYS2 есть куча своих wtf-ов) до первого коммерческого контракта с партнерами, у которых MSVC

получили бы портянки с питоньей дриснёй

Они хотя бы:

1. Типизируются хинтами, имеют кучу валидаторов, линтеров, выправлялок синтаксиса и пр. батареек.
2. Имеют относительно нормальный человекочитаемый синтаксис вместо CMake-ссанины.
3. Для элементарных и частоиспользуемых в системе сборки вещей по типу заменить строку в файле, вызвать внешную утилиту, перебрать что-то в цикле там есть куча удобных и лаконичных конструкций.
4. Удобные dict/list/tuple и пр. примитивы которыми CMake до сих пор не обзавёлся и разработчики серьёзных библиотек как по ссылкам в этом треде вынуждены срать себе в каталоги cmake кривоработающими велосипедами.
5. Адекватный Pattern Matching, который много где пригодился бы в сборочных скриптах, делая их лаконичными.
6. Python для скриптования сегодня знают все и поддерживают все IDE, он используется как язык скриптования в куче инструментов.
7. Не нужно учить откровенно криво спроектированный DSL с овратительнейшим синтаксисом и виндузотной регистронезависимостью.

Ставится MSYS2

Что в конце 2023 года интереснее, MSYS2 или Cygwin?

Сам.

Но там есть генерилки проектов для MSVC и XCode если требуется:

• https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/msvs.py?ref_type=heads
• https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/xcode6.py?ref_type=heads

Почему человечество до сих пор пользуется допотопным круглым колесом? Давно пора эту проблему решить и перейти на квадратное?

Если считаете мою аналогию кривой – покажите, как в исходном коде устанавливаются метаданные об используемых библиотеках. При этом надо учитывать, что в проекте сложнее hello, world код — это десятки, а то и сотни сипипишных файлов.

Что в конце 2023 года интереснее, MSYS2 или Cygwin?

У них так-то разные цели. MSYS2 не реализует POSIX полноценно, тогда как Cygwin старается это сделать, поэтому всякий сложный софт активно юзающий POSIX, к примеру… х.з., Kannel какой-нибудь, соберётся под Cygwin но не соберётся под MSYS2.

А так MSYS2 конечно в 2023 году рулит и педалит.

Он предлагает практически полный набор библиотек и средств разработки, к которым привыкли разработчики в Linux дистрибутивах.

Более того, там есть такие штуки как qt5-static и qt6-static

• https://packages.msys2.org/package/mingw-w64-x86_64-qt5-static
• https://packages.msys2.org/package/mingw-w64-x86_64-qt6-static

То есть ты можешь собрать статическую версию программы на Qt используя простейшие команды по типу:

pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-g++ mingw-w64-x86_64-qt6-static make
qmake CONFIG+=release project.pro
make

И получить stand-alone исп. файл так любимый пользователями Windows.

А ещё там довольно быстрый пакетный менеджер из Arch Linux – pacman. В общем хорошая вещь, многие проекты под Windows собираются в этом окружении, к примеру, KeePassXC.

А как его собственная скорость сборки по сравнению с той же VS или Ninja ?

Я последний раз MSYS (старый, 1.0.11) тыкал несколько лет назад, когда экспериментировал с сетевыми модулями Qt. Саму Qt в статике и проект под неё я собрал «обычным» MinGW, но когда мне потребовался OpenSSL, взял MSYS.

Вполне удобные и подробные. Давай так: что ты в них не нашел?

1. Нет примеров использования каждой опции в каждой команде. В нормальных доках многие функции и параметры иллюстрируются кодом, наглядно объясняющим как юзать эти вещи, для чего они нужны и в каких сценариях их использовать. В доках CMake ничего этого нет. Обычно там крайне скудное и сухое cryptic описание без всяких примеров использования. Пользоваться этим можно, только если ты годами дрочил на CMake, заранее знаешь что тебе нужно найти и используешь доки чисто в качестве справочника. А вот для изучения CMake они полностью бесполезны. Среднестатистические крестовики обычно открывают доки CMake, блюют дальше чем видят, закрывают, идут копипастить примеры из SO и таскать себе FindXXX.cmake скрипты из интернетов.
2. Нет best practices, которые показывают какие команды и опции надо юзать в современных проектах, а какие устарели и не рекомендуются. Де-факто есть два диалекта CMake: легаси и так называемый Modern CMake. Но доки ничего не говорят про эти диалекты. Там просто беспорядочно наблеваны все возможные команды и опции. Типа возитесь с ними сами как хотите.

Я уж молчу о том, что ублюдочный велосипедный DSL нарушает все мыслимые и немыслимые дизайны API. Есть например правило «магическое число семь», гласящее о том, что человек может одновременно держать в голове максимум семь объектов. Некоторые говорят, что на самом деле их еще меньше - четыре. Поэтому дизайнеры API обычно стараются делать не более 4 параметров в каждом методе. Например как в Qt.

Но бездари из Kitware про хорошие практики видимо ничего не слышали. В итоге мы имеем раздутые монструозные команды с десятками параметров и кучей альтернативных режимов работы. Причем в каждом релизе CMake постоянно добавляются все новые и новые команды и параметры, то бишь на уже существующие слои дерьма накидываются с лопаты новые слои дерьма. Ковыряться в этой параше у многих нет никакого желания. Проще бездумно скопипастить решение из SO или спросить у Чата Гопоты.

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

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

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

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

А про CI/CD слыхали?

Слыхали и использовали. И тесты гоняли, и ночнушки собирали. Только делалось это в первую очередь для вантузного проекта, а потом уже для остальных Tier II платформ. Что было банально продиктовано бизнес потребностями и продажами под каждую платформу. ИЧСХ, это даже неплохо работало, потому что за 100% покрытием никто не гнался и юнит тестами покрывались в основном всякие расчетные алгоритмы, геометрические ядра CAD и прочая суровая логика. А все это обычно никак не зависит от ОС/компилятора, поэтому необходимости постоянно гонять CI/CD пайплайн на всех возможных платформах не было.

Не думаю что будет быстрее Ninja, всё-таки Python.

Но каких-то бенчмарков я не нашёл, увы. А так было бы интересно посмотреть все эти Premake, Ninja, Bazel, Qbs, Make в сравнении между собой.

Лучше бы гомитет стандартизации […] придумал бы стандартный пакетный менеджер

Шайка меджународных террористов может разве что объявить единственно верным NuGet :D

С новым MSYS2 ничего собирать не нужно, там уже идёт пакетный менеджер и скомпилированные пакеты. То есть ставишь какой-нибудь Qt, SDL, SDL2 и просто собираешь код.

Но для Qt наверное лучше всё-таки использовать windeployqt вместо статической сборки.

Но для Qt наверное лучше всё-таки использовать windeployqt вместо статической сборки.

Смотря куда. Если делать дистрибутив с 10 экзешниками и 30 DLLями — да.

Но вот тот же DoubleContact у меня — это один жирный бинарь (есть ещё консольный contconv на той же кодовой базе, но его ЦА, думаю, не более 1-2% от общей ЦА пользователей основного проекта). Если даже у пользователя на машине будут стоять кутешные проекты — это будут проекты других авторов, тянущие другие версии Qt. И его собрать статикой значительно выгоднее, даже тупо по объёму дискового пространства. И подозреваю, что у большинства виндового опенсорса, кроме действительно крупных проектов, ситуация примерно такая же.

Да, я с этой проблемой хорошо знаком. У самого есть несколько отдельных несвязанных между собой утилит с GUI на Qt, которые чтобы распространять под виндой лучше линковать статически.

В 2015 году даже делал статические сборки на Qt 4 потому что они весили меньше в два раза, условно 8 МБ против 15 МБ для приложения-кнопки без особой логики.

Пока из того, что я использовал (VS, Make, Nmake, Xcode, Ninja) на одних и тех же проектах Ninja быстрее всего.

За статическую сборку нужно денег занести.

Только для проприетарщиков. А также, если я правильно понимаю суть LGPL, то достаточно поставлять в комплекте объектные или исходные файлы Qt, чтобы не нарушать лицензию.

А также, если я правильно понимаю суть LGPL, то достаточно поставлять в комплекте объектные или исходные файлы Qt, чтобы не нарушать лицензию.

нет конечно. Нужно свои объектные(а также тулчейн) или исходные файлы давать. Чтобы другой пользователь мог слинковать программу со своей версией Qt.

Если собирается под какую-то встраиваемую систему, с проприетарным компилятором, то LGPL фактически вынуждает покупать Qt(потому что ты не можешь предоставить toolchain, а по лицензии ты обязан это сделать)

Для десктопа LGPL норм, если использовать so/dll и собирать свободными компиляторами.

Отчасти поэтому на Android Qt и не взлетел. Лицензия конченная.

Вот одна из статей где подробнее рассматривается лицензия: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/

You must provide a cross-compiling toolchain together with the necessary libraries, headers, files and tools such that users can build the modified Qt version for the target device. A pretty simple way to satisfy this obligation would be to install the toolchain in a virtual machine and make this virtual machine available to the users.

Для OSS проектов?

https://winlibs.com/

Оно не такое жирное как MSYS/Cygwin.

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

И все дистрибутивы Линукса дружно наложат на этот пакетный менеджер анафему потому что у каждого дистрибутива уже есть родной пакетный менеджер.

OSS

Знал бы я, что значит :-)

Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.[1][2]

https://en.wikipedia.org/wiki/Open-source_software

Хм, да вроде бы очень распространённая аббревиатура, чтобы уточнять.

Open Sound System

Нет примеров использования каждой опции в каждой команде

А в том же Qt они точно есть? Прямо таки на все аргументы?

Нет best practices, которые показывают какие команды и опции надо юзать в современных проектах, а какие устарели и не рекомендуются. Де-факто есть два диалекта CMake: легаси и так называемый Modern CMake. Но доки ничего не говорят про эти диалекты. Там просто беспорядочно наблеваны все возможные команды и опции. Типа возитесь с ними сами как хотите.

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

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

Так и Qt также же. И много с чем еще. Основы нужно в книгах статьях учить.

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

Не считают его верхом эволюции. Но на данный момент более универсального формата описания проекта и сборки нету.

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

Вот про «портянки ссанины» мне не очень нравится. И что значит «куда сможешь дотянуться». У меня нет самоцели. Просто при создании нового проекта я возьму Qt Creator + CMake.

а есть множество кейсов, где удобнее проекты IDE

Есть сомнения

А я загуглил https://en.wikipedia.org/wiki/Operations_support_system

Для OSS проектов?

Open-source software

Я думал да. Хотя могу ошибаться.

Просто при создании нового проекта я возьму Qt Creator + CMake.

А мог бы взять qmake, в течении жизненного цикла Qt5 и Qt6 она точно поддерживается (а может, и дальше). Перейти на плохо читаемые портянки никогда не поздно, вот слезть с них…

Очередной слышавший звон, но абсолютно не понявший его сути. Я уже перестал удивляться.

В контексте моего комментария вообще получается, что я за статическую сборку GPL-проекта должен деньги кому-то заносить, ЛООООООООЛ.

Даже для проприетарщины это не всегда так, кстати. LGPL (про которую и родился этот миф) нигде не запрещает статическую сборку. Она только накладывает условия распространения. Поставщик должен обеспечить возможность получателю сборки с другой совместимой версией Qt. ВСЁ. Один из способов это сделать описали в комментариях выше. Те, кого условия LGPL не устраивают, могут купить у троллей коммерческую версию, только и всего. И разумеется, это всё исключительно про распространение, для внутреннего употребления свободные исходники можно собирать как угодно.

Могу, впрочем, утешить, ты не первый и кажется, даже не пятый, кто транслирует это. Пора это в какой-нибудь FAQ заносить.

А мог бы взять qmake

и поиметь хорошо читаемую портянку

greaterThan(QT_MAJOR_VERSION, 4) {
win32 {
tr.commands = lrelease \
    $$_PRO_FILE_
}
unix {
macx {
tr.commands = lrelease \
    $$_PRO_FILE_
} else {
tr.commands = lrelease-qt5 \
    $$_PRO_FILE_
}
}
} else {
win32 {
tr.commands = lrelease \
    $$_PRO_FILE_
} else {
tr.commands = lrelease-qt4 \
    $$_PRO_FILE_
}
}

которая в linux падает на сборке с Qt5