Pull to refresh

Comments 14

Просто интересно:

Если почитать про Go, там вообще специально сделано так, что структура проекта сама по себе позволяет обойтись без cmake и ему подобных и для сборки просто делаешь go build…

Спасибо за статью, буду ждать продолжения.

P.S. Вспомнил почему-то как собирал KDE 4.0 из какого-то экзотического overlay Gentoo :-)
Вообще, писать add_definitions для флагов компиляции есть не очень хороший тон. Для этих целей лучше использовать либо set(CMAKE_CXX_FLAGS "-лала"), либо для цели set_target_properties(ProjectName PROPERTIES COMPILE_FLAGS «flags»).
Потом, Ваше решение с add_definitions не шибко кроссплатформенное — компилятор Microsoft'а понятия не имеет, что такое, например, "-Wall".
Поэтому код, скорее всего, будет выглядеть как-то так:
if(MSVC)
	set_target_properties(ProjectName PROPERTIES COMPILE_FLAGS "/W3")
elseif (CMAKE_COMPILER_IS_GNUCXX)
	set_target_properties(ProjectName PROPERTIES COMPILE_FLAGS "-Wall -pedantic")
else()
	message("Unknown compiler")
endif()

Ну и для остального в таком же духе.
Естественно, set_target_properties нужно выполнять после add_executable.

CMake — отличная система сборки, всем интересующимся рекомендую потратить некоторое время на ее изучение — потом все переведете на CMake, без нее даже «Hello, World» забирать не будете.
Пытался недавно перевести один проект на CMake. В оригинале был .sln (VS 2005), в нем куча проектов. При этом есть 32 битный проект DLL и 64 битный проект DLL, которые собираются, а потом в качестве ресурсов помещаются в целевой exe.

Не смог перевести на CMake, потому что он — как мне говорили — не поддерживает генерацию файла .sln с проектами разной битности :(
Да, CMake генерирует солюшен либо для x86, либо для x64. И это скорее логично, чем нет.

Может, конечно, и есть какие-то хайфхаки на этот счет, но я никогда такими проблемами не задавался. Самым логичным решением тут, как кажется мне, будет разбивка всего решения на 32 и 64 битные проекты, а потом, после компиляции в нужном порядке, все необходимое помещать в exe'шник. Хотя странно все это.
Конечный exe — это упаковщик исполняемых файлов, а те две длльки разной битности — это «стабы», которые надо помещать в генерируемые упаковщиком exe файлы.

Можно разбить, собирать в несколько стадий, но красота теряется, прямо скажем.
А сделать exe для x86 и x64 версии отдельно по каким-то причинам нельзя?

И как сделали в конечном итоге? Если в sln оставили — так может CMake и нафиг не нужен был?
Отдельные сборки не вполне хорошая идея, потому что пользователь может упаковывать файлы любой битности. Можно было бы, конечно, из главного приложения вызывать вспомогательное соответствующей битности, но мне не очень симпатична такая идея.

Да, в итоге остается прежний sln, но его неудобно поддерживать: много проектов, и модификация одного или добавление нового превращается в небольшое приключение.
В таком случае можно попробовать либо писать просто make файлы — так Вы сделаете именно то, что хотите, но пропадет удобство использования солюшенов VS.

Еще можно попробовать использовать систему сборки waf. Система использует язык Python со всеми его плюшками, вроде бы там можно сделать то, что Вы хотите. Точно смогу проконсультироваться с нашим спецом по waf после праздников и дать однозначный ответ.
Да это моя ошибка, а скорее лень.
Cуммируя ваше замечания напишу что
set_target_properties(myexe_target PROPERTIES COMPILE_FLAGS "-Wall") — устанавливает опции для отдельной цели

а set(CMAKE_CXX_FLAGS "-Wall") — для всех целей впринципе
Ну это скорее не ошибка, а просто логическая несостыковка.
В остальном да, Вы все верно написали :) Спасибо за статью, ждем продолжения!
А он, cmake, умеет под Keil или iar собирать? Для эмбеда это весьма, бывает, надо.
К сожалению нет. Да и как вы думаете кто будет создавать кодогенератор под данные студии для CMAKE-а? Единственно, что позволяет использовать плоды CMAKE-а — открыте elf файл-ов в Keil uVision

Хотя конечно кросскомпиляция доступна, то есть проект для IDE вы не соберёте, но скомпилировать можно. Но у меня нет опыта да и стимула этим заниматься — пока я остановил свой выбор на кросскомпиляцию под AVR-GCC и ARM-GCC, но об этом я тоже напишу поже.
пжлста) — жаль в ядро пока не взяли ) заместо lzo или в brtfs
Sign up to leave a comment.

Articles