C++ и опции компиляции

Современные средства сборки (cmake, autotools)

жуткое зло.

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

Если вы С++ разработчик, то верно ли будет сказать следующее: для 90% приложений для сборки достаточно было бы просто детектирование флагов через pkg-config, поддержка --with/--without флагов и просто ручное указание флагов для конкретного файла (чтобы вставить костыль)?

И в чём проблема это всё сделать с помощью autoconf/automake? :)

Кстати, флаги для pkg-config далеко не все софтинки предоставляют

например, нужная фича - на одной платформе нужен один набор библиотек, на другой - другой. Скажем, то, что на линуксе входит в состав glibc, на фреебсд лежит в отдельной библиотеке (уже не помню что). А на винде так вообще всякие kernel32 и прочие

Ещё проверку версий библиотек на совместимость не упомянул

Я спрашиваю какифе фичи время показало ненужными

Кстати, флаги для pkg-config далеко не все софтинки предоставляют

Пусть идут в жопу. Вот это и есть багом кстати, который лучше просто пофиксить

например, нужная фича - на одной платформе нужен один набор библиотек, на другой - другой

Есть одна платформа - linux, и Поттеринг - пророк ее. Остальные пусть прыгнут с моста. Аппаратные платформы - да, но на то и 10% которые я упомянул. Если писать низкоуровневую библиотеку, тогда да, но что-то мне подсказыывает что 90% серверного софта - linux программа на x86_64

В принципе да, это важно

Использую qmake даже для безQtёвых проектов ^_^

А краткий список используемых фич? Есть какая-то сложная логика?

Серверный софт не нужен без клиентского. А у клиенсткого зоопарк платформ явно побольше будет. Да и оппоттерингованный линукс тоже не нужен.

Ещё даже на одном и том же линуксе для разных аппаратных платформ для поддержки одной и той же фичи могут понадобиться разные библиотеки

Потому для домашний лейсапедов написал свою.

И сколько времени ты на неё потратил?

Хрен его знает. Может 7-10 вечеров. Это не билдсистема в обычном смысле. Это билд-сервер, который многопоточно компиляет минимально необходимое количество файлов после их изменения на диске. А почему спрашиваешь?

Ну вот автотулзы тоже можно было бы идеально выучить за те же 7-10 вечеров и многопоточно компилять минимально необходимое количество файлов после их изменения на диске :)

Ой не совсем это то же самое. Они лапшой от этого не перестают быть. А теперь у меня двухстрочечные Python конфиги

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

Autotools - адская лапша везде

qmake. Не особо критично.

использую -march=native -O3 -funroll-loops, порой зачётно прибавляет пирформанса на чужом коде

...pkg-config, поддержка --with/--without и просто ручное указание флагов для конкретного файла (чтобы вставить костыль)?..

В 90%, может, и достаточно (хоть я и не понял, о чём речь), но рассчитывать на эти 90 — ссзб, если только ты не специализируешься узко на чём либо. Ну то есть если заведомо будут использоваться только знакомые pkg-config библиотеки и целевой тулчейн всегда один одной и той же версии...

Я использовал cmake. Не доволен я им абсолютно, но костыли в нём есть почти для всего. Как я понимаю, почти все системы сборки позволяют городить всё что угодно — условия, циклы, прямое указание опций компилятора, запуск любых программ. Декларативных я ни разу не пробовал и (хоть мне и нравится идея) не слышал ни разу об историях успеха. Рано или поздно любая система сборки превращается в ещё один язык программирования.

Что я использовал в cmake:

• 'make install' target'ы для произвольных файлов (конфиги по умолчанию, например)
• subproject_add компилировал другие cmake (и даже не cmake) проекты статически и линковался к ним
• • т.к. не все субпроекты поддерживали cmake, иногда применял костыли вроде move, copy, remove команд
• разумеется, --with и --without поддерживали нормальный вывод об ошибке если не найдены все нужные библиотеки
• проверял c++-заголовочные-файлы на определённые define'ы в библиотеках
• различные опции для сборки профилируемого бинарника, отладочного и релизового
• заполнял configure.h всякой инфой типа опций, путей файлов (не всё что я кодил можно было запустить не устанавливая, иногда install_prefix компилировался в бинарник)

Нужно отслеживание зависимостей внутри проекта, cmake это умеет. Нужно отсутствие вот этого:

Детектирование возможностей системы, поиск заголовочных файлов, размеров типов в памяти и умные решения по поводу компиляции

Отучить cmake от этого нетривиально, но я был настойчив, так что теперь им и пользуюсь :)

проверял c++-заголовочные-файлы на определённые define'ы в библиотеках

Когда это нужно?

заполнял configure.h всякой инфой типа опций, путей файлов (не всё что я кодил можно было запустить не устанавливая, иногда install_prefix компилировался в бинарник)

Зачем это если везде есть /etc/your_project и в нем можно положить дефолтный конфиг и опции в нем перекрыть в ~/.config/your_project?

проверял c++-заголовочные-файлы на определённые define'ы в библиотеках

Когда это нужно?

например, библиотека собрана с какой-то опциональной фичей, и этот факт отмечен определённым #define-ом

А без этой фичи твоя программа не работает, поэтому неплохо бы проверять её наличие

Скажем, то, что на линуксе входит в состав glibc, на фреебсд лежит в отдельной библиотеке (уже не помню что).

Наоборот) во FreeBSD вызовы dlopen() и dlclose() входят в состав libc, а в случае с линуксом libdl.

точно, именно про это и говорил, перепутал малость :)

Когда это нужно?

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

~/.config/your_project

имелись в виду опции которые определяют логику сборки программы и. например --with-sound=(openal|sdl) или использовать ли например double или float для вычислений ну и т.д

Мне казалось, что autotools говно, пока я не познакомился поближе с cmake. Вот уж говно так говно. Говнище.

Если вы С++ разработчик, то верно ли будет сказать следующее: для 90% приложений для сборки достаточно было бы просто детектирование флагов через pkg-config, поддержка --with/--without флагов и просто ручное указание флагов для конкретного файла (чтобы вставить костыль)?

+ Опции для путей (--prefix, --sysconfdir и т.п.).

+ Проверки «поддерживает ли компилятор такой-то флаг».

+ Проверки «есть ли такой-то системный заголовочный файл».

Пробовал под оффтопиком?

Под онтопиком.

Доп вопрос: какие фичи используете вы для сборки собственноручно написаного софта (в том числе на работе) и эти фичи критичны для вас?

Precompiled headers, к примеру. В cmake делается через жопу и не кроссплатформенно.

кроссплатформенно

Если быть точнее некросскомпиляторно? Или все же платформа?

Я так понимаю что в precompiler header собирается несколько часто используемых заголовочных файлов, собирается pch, потом он передается через аргумент командной строки компиляторам в тех случаях, когда он также включается в сам файл. Кстати, разве тут нет небольшой разницы, ведь теперь файл не включен там где он был включен раньше, а строго дописывается в начало файла. Это обычно индифферентно и проблем не вызывает? Есть какие-то еще thumbs up rules с precompiled headers?

Пишу вручную Makefile, для 90% на работе хватает.

некросскомпиляторно

Именно. В gcc оно более автоматически происходит (не надо явно указывать хедер для каждого сорца).

Я так понимаю что в precompiler header собирается несколько часто используемых заголовочных файлов,

Обычно один хедер, который инклудит все нужные. Классика венды - StdAfx.h + компилируемый в .pch StdAfx.cpp (состоящий из одного #include StdAfx.h).

собирается pch

Часто не один, а несколько - для разных подсистем приложения разные. Ну и хедеры разные.

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

Ну если проект изначально пишется с расчетом на precompiled headers, то это изначально так. Та же MSVS тупо игнорит весь код до нахождения нужного #include, если ей сказано юзать pch. Потому всегда вначале.

Да, gcc же по дефолту ищет свои .gch прямо в сорцах, что не есть кул - надо выносить в builddir.

Ну я для своих поделий ограничиваюсь clang++, таи вроде так как я говорил

ну и где это твое говно на гитхабе? показывай публике, че в пустую болтать