Да, например, под маком переменную CMAKE_OSX_SYSROOT нужно выставлять обязательно ДО команды project().
но это все такие нюансы, с которыми может не каждый столкнуться, а пихать все-все в статью для новичков — только отпугнет их… нужно как-то придерживаться золотой середины между простотой и полнотой.
Интересно было бы услышать пример, как дизайнеру внести баг в ПО. Только если дизайнер не знаю, сам клиентской версткой не занимается, и таким образом, не создает код.
Если что, в моем понимании «косяк проектирования/юзабилити» != «баг». Т.е. то что в макете кнопка ховером не отмечена — я бы багом не назвал. Если дело только в этом, тогда могу согласиться с вами)
Нет, помимо std там там есть и концептуальные проблемы.
Dan Saks потрясающее видео на эту тему сделал: www.youtube.com/watch?v=D7Sd8A6_fYU
Можно сколько угодно распинаться о преимуществах С++, усилия будут тщетны, пока разработчик на С не будет слышать то что лично ЕМУ нужно.
Посмотрел. Вопросы, конечно, возникли, но раз вы извинились, то озвучивать ничего не буду)
В целом есть ощущение что для CMake не хватает своего подобия boost или GSL — все лепят свои велосипеды (у KDE тоже есть свое подобие utk). Хорошо бы заморочиться сделать единый стиль и единые гайдлайны, которые покроют потребности большинства)
У нас примерно 10к cmake скриптов на 1M строк С++. мне кажется, это разумное соотношение. С учетом того что там делается много всего — работа с пакетами, бандлы, обжимка разных инсталляторов и их перепаковка и тп.
Отвечаю: find_package(phpcpp) будет искать скрипт FindPhpcpp.cmake по путям, известным cmake (MODULE_SEARCH_PATH, а так же его стандартная библиотека).
find_file — самая низкоуровневая штука. Говоришь имя файла, и где искать — функция перебирает известные директории, и если находит, то выставляет выходную переменную в значение полного пути к файлу.
find_library — некоторая расширенная версия предыдущей функции. Может найти в перечисленных каталогах статичную библиотеку, динамическую, а так же учитывает платформозависимый префикс вроде «lib» и версионные симлинки (unix).
Эти две функции обычно разработчиками cmake-биндингов библиотеки активно используются в Find* скриптах.
find_package — высокоуровневая штука. вы ей говорите — «хочу Qt5Core», она и инклюды найдет, и библиотеку, и флаги, если нужно дополнительные определит. Обычно получается что у вас уже есть Qt5::Core какой-нибудь или boost::thread, который вы просто указываете в target_link_libraries и радуетесь в жизни (инклюды прокинутся тоже).
Про последнее — поддерживаю, написать один раз application.rc.in, туда всю метаинформацию упрятать и использовать шаблон для разных приложений (если в продукте оно не одно)
Что там за опасное заблуждение, простите? Комментатор вам сказал «станадртная либа жирная для embedded» — это никто оспаривать не будет, даже члены комитета С++. Почему вы пытаетесь что-то другое в комменте видеть?
Из-за того что обработка исключений генерирует code-bloat, и появился www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
очередной метод обработки ошибок. С текущей реализацией STL под bare metal очень и очень слабо юзабелен.
Я сам мудохался с тем чтобы под вполне себе комфортные 8мб на плюсах писать. Да, в итоге все же остановился на коде с поддержкой исключений, но какие же они жирные…
Цели в cmake — потрясающая вещь. Это с одной стороны, глобальная переменная, которая при этом еще и объект) К сожалению, из-за примитивного синтаксиса, так просто их методы не подергать, приходится довольствоваться get_target_property/set_target_properties. Одно из замечательных свойств то, что можно для цели выставлять свои значения, не определенные стандартом (но и по понятным причинам без особой надобности это лучше не делать — огребешь проблем с совместимостью).
Почему я так положительно об этом отзываюсь? Ну, например, это позволяет написать систему фиксапа (расчета рантайм-зависимостей) полностью определяемую на этапе конфигурирования — она будет работать куда быстрее чем то что есть в bundleUtiities.
уместным тут будет упомянуть функцию if (TARGET smth), которая позволяет проверить что цель уже определена (если например, вы хотите реализовать жесткий порядок определения зависимостей в своей DSL-функции)
Теперь Вы способны писать свои и понимать чужие CMake-файлы
Мне кажется, без объяснения механизма cmake_parse_arguments это вообще невозможно.
Эта команда позволяет легко и непринужденно воротить в собственном проекте некое подобие DSL поверх cmake, например:
(скопипастил из реального кода).
Мы вроде помним, что в cmake иного типа, нежели vector(string), нет. Как же достигается построение функций, которые принимают нечто похожее на хеш-таблицы?
Очень просто, вводятся некоторые «маркерные» значения. Они могут быть либо опциями сами по себе, либо сигнализировать, что после них идет значение (одинарное либо список).
функция cmake_parse_arguments принимает всё это добро и раскладывает по полочкам — каждый список либо значение в отдельную переменную.
Это позволяет создавать из процедурного языка — некое подобие декларативного. Этим подходом в разной степени пользуются все крупные проекты.
Вот пример из кода opencv, не для целей, а для опций, правда:
OCV_OPTION(OPENCV_GENERATE_SETUPVARS "Generate setup_vars* scripts" ON IF (NOT ANDROID AND NOT APPLE_FRAMEWORK) )
project(MyProject VERSION 1.2.3.4 LANGUAGES C CXX)
У кого-то может возникнуть вопрос — а нафига может понадобиться вообще версию там указывать?
Это может использоваться в двух вещах:
-автоматическое версионирование so/dylib на unix-платформах (симлинки, все дела)
-интеграция с CPack и выставление версии продукта там
Данный код, помимо проверки версии, что немаловажно, еще и выставляет все флаги совместимости (cmake policy) в соответствие с этой версией.
Можно выставить низкую версию, и нужное поведение, сломавшее обратную совместимость после ее выхода докрутить ручками. Так делают разработчики библиотек, которые хотят поддерживать древние версии cmake, но при этом и новые фичи местами использовать.
«Лицензия — любая.» ну вот мне кажется опасное дело.
Тот же Microsoft, на который вы не хотите работать, условно, выложит исходники Windows под лицензией «вообще ничего нельзя, только читать, даже копировать исходники нельзя». Утрирую намеренно. Какой-то ящик Пандоры получится. Может хотя бы остановиться на одобренных OSI?
Да и в текущей схеме не очень понятно. Первое что приходит в голову: у меня есть профиль на гитхабе, я туда заклонил Chromium, и проверяю его бесплатно. При этом работая на Гугл (об этом вам не сообщая).
Если честно, мне как индивидуальному разработчику схема с комментариями пока ближе, новая больше злоупотреблений вызовет.
Можете объяснить одну вещь — разве нахождения OpenAL*.dll в директории с исполняемыми файлами недостаточно? Зачем ее вообще необходимо в системную директорию-то копировать?
Т.е. почему нельзя сделать что-то вроде как в Qt сделано с opengl реализацией:
1) проверяем, есть ли реализация в системе
2) если ее нет или она нас не устраивает (LoadLibrary зафейлилась) — переименовываем OpenAL_dist.dll в OpenAL.dll в директории с программой. (ну это если мы в Roaming/пользовательской директории. Если нет, то да, надо права запросить — но один черт мы в систему не срем)
но это все такие нюансы, с которыми может не каждый столкнуться, а пихать все-все в статью для новичков — только отпугнет их… нужно как-то придерживаться золотой середины между простотой и полнотой.
cmake.org/cmake/help/v3.0/variable/BUILD_SHARED_LIBS.html
чтобы у других разработчиков было привычное понимание) Ну это если вы действительно хотите переключалку режима сборки.
Если что, в моем понимании «косяк проектирования/юзабилити» != «баг». Т.е. то что в макете кнопка ховером не отмечена — я бы багом не назвал. Если дело только в этом, тогда могу согласиться с вами)
Dan Saks потрясающее видео на эту тему сделал:
www.youtube.com/watch?v=D7Sd8A6_fYU
Можно сколько угодно распинаться о преимуществах С++, усилия будут тщетны, пока разработчик на С не будет слышать то что лично ЕМУ нужно.
В целом есть ощущение что для CMake не хватает своего подобия boost или GSL — все лепят свои велосипеды (у KDE тоже есть свое подобие utk). Хорошо бы заморочиться сделать единый стиль и единые гайдлайны, которые покроют потребности большинства)
find_file — самая низкоуровневая штука. Говоришь имя файла, и где искать — функция перебирает известные директории, и если находит, то выставляет выходную переменную в значение полного пути к файлу.
find_library — некоторая расширенная версия предыдущей функции. Может найти в перечисленных каталогах статичную библиотеку, динамическую, а так же учитывает платформозависимый префикс вроде «lib» и версионные симлинки (unix).
Эти две функции обычно разработчиками cmake-биндингов библиотеки активно используются в Find* скриптах.
find_package — высокоуровневая штука. вы ей говорите — «хочу Qt5Core», она и инклюды найдет, и библиотеку, и флаги, если нужно дополнительные определит. Обычно получается что у вас уже есть Qt5::Core какой-нибудь или boost::thread, который вы просто указываете в target_link_libraries и радуетесь в жизни (инклюды прокинутся тоже).
1. создаем version.h.in:
2. вызываем
3. включаем в коде диалога хидер version.h, радумемся
Парсинг хедер файлов — не очень идея (хотя в редких случаях так можно сделать для какого-то 3rdparty кода, чтобы не дублировать константы у себя).
Из-за того что обработка исключений генерирует code-bloat, и появился
www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
очередной метод обработки ошибок. С текущей реализацией STL под bare metal очень и очень слабо юзабелен.
Я сам мудохался с тем чтобы под вполне себе комфортные 8мб на плюсах писать. Да, в итоге все же остановился на коде с поддержкой исключений, но какие же они жирные…
Почему я так положительно об этом отзываюсь? Ну, например, это позволяет написать систему фиксапа (расчета рантайм-зависимостей) полностью определяемую на этапе конфигурирования — она будет работать куда быстрее чем то что есть в bundleUtiities.
уместным тут будет упомянуть функцию if (TARGET smth), которая позволяет проверить что цель уже определена (если например, вы хотите реализовать жесткий порядок определения зависимостей в своей DSL-функции)
Мне кажется, без объяснения механизма cmake_parse_arguments это вообще невозможно.
Эта команда позволяет легко и непринужденно воротить в собственном проекте некое подобие DSL поверх cmake, например:
(скопипастил из реального кода).
Мы вроде помним, что в cmake иного типа, нежели vector(string), нет. Как же достигается построение функций, которые принимают нечто похожее на хеш-таблицы?
Очень просто, вводятся некоторые «маркерные» значения. Они могут быть либо опциями сами по себе, либо сигнализировать, что после них идет значение (одинарное либо список).
функция cmake_parse_arguments принимает всё это добро и раскладывает по полочкам — каждый список либо значение в отдельную переменную.
Это позволяет создавать из процедурного языка — некое подобие декларативного. Этим подходом в разной степени пользуются все крупные проекты.
Вот пример из кода opencv, не для целей, а для опций, правда:
p.s. а еще можно там реализовать вещи вроде
Квадратные скобки это вообще удивительная магия, про них можно отдельную статью писать)
project(MyProject VERSION 1.2.3.4 LANGUAGES C CXX)У кого-то может возникнуть вопрос — а нафига может понадобиться вообще версию там указывать?
Это может использоваться в двух вещах:
-автоматическое версионирование so/dylib на unix-платформах (симлинки, все дела)
-интеграция с CPack и выставление версии продукта там
Данный код, помимо проверки версии, что немаловажно, еще и выставляет все флаги совместимости (cmake policy) в соответствие с этой версией.
Можно выставить низкую версию, и нужное поведение, сломавшее обратную совместимость после ее выхода докрутить ручками. Так делают разработчики библиотек, которые хотят поддерживать древние версии cmake, но при этом и новые фичи местами использовать.
Тот же Microsoft, на который вы не хотите работать, условно, выложит исходники Windows под лицензией «вообще ничего нельзя, только читать, даже копировать исходники нельзя». Утрирую намеренно. Какой-то ящик Пандоры получится. Может хотя бы остановиться на одобренных OSI?
Если честно, мне как индивидуальному разработчику схема с комментариями пока ближе, новая больше злоупотреблений вызовет.
Т.е. почему нельзя сделать что-то вроде как в Qt сделано с opengl реализацией:
1) проверяем, есть ли реализация в системе
2) если ее нет или она нас не устраивает (LoadLibrary зафейлилась) — переименовываем OpenAL_dist.dll в OpenAL.dll в директории с программой. (ну это если мы в Roaming/пользовательской директории. Если нет, то да, надо права запросить — но один черт мы в систему не срем)
Что не так с предложенной идеей?