Сборка проекта на плюсах

Сделать отдельно makefile для linux и проект msvc для винды. Будет правда дублирование работы что и там и там вносить правки, но зато безо всяких cmake и прочей ереси.

Будет правда дублирование работы

В этом проблема, хочется «х-х и в продакшн». Вот у меня есть файлик для meson:

project('...', 'c',
            default_options: 'c_std=c11')

sdl2_dep = dependency('SDL2')
sdl2_image_dep = dependency('SDL2_image')
sdl_deps = [sdl2_dep, sdl2_image_dep]



src = [....]
executable('demo', sources: src, dependencies: sdl_deps)

И все, этого хватит, чтобы скомпилироваться везде где есть meson и зависимости. Но это, конечно, проект маленький вот и файл сборки простой.

premake5, правда он делает генераты, которые уже скармливаешь make, mvc и пр.

https://xmake.io/ можно попробовать. Что-то вроде premake5, но без вечной альфы и может собирать проект сам, а не только генерировать. Идёт вместе с пакетным менеджером и вроде может тянуть пакеты из конана, vcpkg и т.д.

premake5

Прикольная вещь – поизучаю на досуге.

правда он делает генераты, которые уже скармливаешь make, mvc и пр.

Ну сейчас это, по моему, норма: генератор в *make либо ninja.

Qbs

автотулзы лучшие

Подскажите книги или статьи на тему компиляции и пересборке приложений (комментарий)

Тоже интересная вещь и то, что может тянуть пакеты это хорошо.

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

В чем у тебя проблемы с cmake? Я работаю с cmake и в linux и в винде (с msvc). Где у тебя была боль? В чтении документации? Давай без всяких громких заявлений про боль и страдания, а факты и конкретные проблемы.

Ну в идеале, как мне кажется, если приходиться бороться с системой сборки или искать помощи по решению проблемы, которую нельзя решить чтением манов, то это плохая система сборки. Вот есть тот же Makefile, я могу написать спокойно написать Makefile (без ужасных @*@@**@$) и все будет работать, а с CMake (для одного и того же проекта) мне приходилось постоянно что-то гуглить, читать SO и просить помощи.

С meson у меня аналогичная ситуация, по оф. манам я могу написать meson.build и оно будет просто работать.

И чем это структурно бл… отличается от CMake?

Fastbuild

CMake, в качестве ПМ vcpkg.

CMake, в качестве ПМ vcpkg.

+1

Ну вот допустим моя старая проблема. Я тогда потратил очень много времени сначала на самостоятельный поиск проблемы (и да, я прочитал кучу манов и кучу вопросов на SO), потом мне подсказали с find_library. После этого, я не особо хочу вспоминать о CMake

Сборка проекта на плюсах (комментарий) вот тут ссылка на cmake-файл для этого же проекта что собирает этот meson-файл. Только для meson я написал так как в мане и все заработало сразу, а с CMake так же как в мане не работало.

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

ЗЫ: От СМаке уже блевать тянет.

cmake он как lisp, пока пользуешься, все кристально ясно, но стоит его забросить и вот это уже нагромождение скобочек в s-записи + свои причуды в реализации, я сейчас уж не помню что, но были там костыли которые работали только при определенном виде использования и это было крайне не логично по крайне мере для меня на тот момент когда я с этим столкнулся. А одно помноженное на второе вызывает боль, и запись большинству чуждая и костыли попадаются какие-то нелепые.

Ну cmake действительно весьма «специфичная» штука, многословная документация, понимать её сложно из-за нагромождения абстракций. Вот взять генерацию и установку конфиг файлов:

include(CMakePackageConfigHelpers)
	write_basic_package_version_file(${PROJECT_NAME}ConfigVersion.cmake
		COMPATIBILITY AnyNewerVersion
		ARCH_INDEPENDENT)
	install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
		DESTINATION lib/cmake/${PROJECT_NAME})

	install(EXPORT ${PROJECT_NAME}Config
		NAMESPACE ${PROJECT_NAME}::
		DESTINATION lib/cmake/${PROJECT_NAME})
	export(EXPORT ${PROJECT_NAME}Config
		NAMESPACE ${PROJECT_NAME}::)

Ну это же дерьмо какое-то. Но основная проблема cmake - для чего он генерит файлы для других систем, а не компилит напрямую? Странная задача, ВСтудия должна сама читать CMake, если он ей нужен.

ВСтудия должна сама читать CMake, если он ей нужен.

Так она вроде и читает. Три года назад ей пользовался и она предлагала создать CMake проект и, по-моему, она даже сама его заполняла для компиляции.

А зачем на оффтопике собирать?

Даже так, это правильно. Тем актуальнее вопрос - зачем CMake делает то, что он делает …

Ну к примеру, если юзер использует оффтопик

Если у вас такая аллергия на CMake, а с Meson все хорошо, то зачем искать что-то ещё. Или Meson тоже не идеален и приходится изучать его слишком глубоко?

Есть прекрасное решение этой проблемы – заплатить за создание и сопровождение сценариев сборки знатоку.

Щас вроде какое-то ninja подвезли, а так CMake, да. Боль, да. А что в C/C++ проектах больше хеловорлда не боль?

Для оффтопика и бинарника хватит. Нафига виндузятнику что-то собирать?

make и mingw для кроссконпеляции под винду

ninja это условный make, а cmake задумывался как кроссплатформенный оркестрант над всякими условными make.

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

xmake смотрится интересно, может и cmake проекты подключать. Только пока не нашёл - как сгенерить и установить аналог config файлов cmake’а? Т.е. что-то, что можно установить локально в систему, и потом подключить из других проектов. И не какой-нибудь очередной новый формат, а какой-нибудь pkgconf файл.

Установли какой-то первый попавшийся проект на xmake’е, автор вообще на заморачивался о install целях, и о создании подключаемых в других проектах файлах, но при установке в /usr/lib создались как pkgconfig, так и cmake файлы. Даже не знаю, может это даже излишняя автоматизация, главное чтобы руками можно было в случае чего подрихтовать.

Пока ничего так, вполне. Спасибо за наводку.

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

но можно упариться в депенденсах перечислять хидеры, что бы при изменении хидера, всё пересобиралось

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

единственная проблема cmake на мой взгляд

разрабы часто меняют версионность самого cmake

и старые конструкции могу не работать в новых версиях

в целом есть только одна книга, которая постоянно обновляется

и которую можно использовать как учебник по cmake

Professional CMake: A Practical Guide, Craig Scott

С meson те же проблемы на любом нетривиальном использовании – а ответов на SO мало, meson еще молодой. Документация meson очень уступает документации CMake при этом – в последней есть ответы на практически все вопросы.

Ты всё правильно написал, CMake лютое говно. Параша параш. Хуже него разве что дуротулз.

Лучше действительно выбрать Makefile + проект для Windows.

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

Попробуй qbs.

Waf!

Это все абстрактное. Нелогично, костыли, не нравится…

Это все абстрактное.

Можно ли эти «Авгеевы конюшни» /cmake/ разгрести? …

Так проблема в том, что ты не разобрался, как прдключить SDL2. А если изучил состав пакетов SDL2, то увидил бы, что там нет конфигурационного файла для cmake. Зато есть pkg-config, который тоже можно использовать в cmake.

1. По команды cmake вполне логичны. Главное понимать, зачем какая-команда нужна.

2. И что?

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

По команды cmake вполне логичны

Сомневаюсь, что то место из cmake доки, где рассказывается об установке файлов проекта в систему с наскока осилит хотя бы один нормальный человек, там всё алогично. Мне и самому придётся разбираться в этом своём же сниппете в следующий раз.

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

Опять ты, копрофаг.

копрофаги — это любители симейка и прочих

Да, согласен, я не изучил состав SDL2, потому что я наивно полагал, что загуглив «CMake SDL2», и найдя там репозиторий, который упоминается в том топике, то я решу все свои проблемы.

Сейчас я погуглил, там и про pkg-config и еще вот такой .cmake файл ссылка

А, вот и ты наткнулся на типичные проблемы на ровном месте, которые создали тебе макаки (разработчиками назвать их нельзя) из Kitware, которые созадали этот свой CM*ke: Оценки хелловорлда тред (комментарий)

Именно из-за их идиотских решений сегодня разработчики на C++ как последние виндузятники ползают по помойками в поисках FindModules для нужных библиотек. CMke вообще виндуозное дерьмецо с этим их case-insensitive. А как начнёшь пользоваться этим CMke-дерьмом более активно, к типичным проблемам с зависимостями добавится ещё вот это: За что так не любят cmake? (комментарий)

Так что хорошо, что CMake для мира Linux подмирает уже прямо как craptools. Red Hat все значимые Linux-проекты вроде X.Org, Mesa, GNOME, Wayland, systemd и пр. перевёл вместо CMake на Meson и правильно сделал.

сегодня разработчики на C++ как последние виндузятники ползают по помойками в поисках FindModules для нужных библиотек

Зачем где-то лазить, если есть conan, vcpkg и нативная интеграция pkgconfig?