Ответы пользователя по тегу Кроссплатформенность
  • Как включить в статическую библиотеку все зависимости из других стат.библиотек в CMake проекте?

    Nipheris
    @Nipheris Куратор тега C++
    Господи, что ж тут за костыли насоветовали))

    Этого хотелось бы избежать, то есть нужно, чтобы все зависимости от boost были уже включены в mylib.

    Как верно отметил jcmvbkbc , обычно одна стат. библиотека не тащит в себе другую. Более того, такая возможность - включить одну стат. библиотеку в состав другой - мало где существует, я знаю про поддержку такой фичи только в Visual Studio. Ну т.е. это нечто из ряда вон выходящее, а не привычный workflow. По-нормальному вы должны указывать при линковке стат. библиотеки все её зависимости. Следовательно, вопрос в том, как эту информацию о транзитивных зависимостях статической библиотеки передавать и использовать при линковке с ней.

    pkg-config в общем вполне нормальное решение, но это уже не совсем "в рамках CMake".
    В рамках CMake всё делается с помощью target_link_libraries и экспорта симейк-конфига в паре с файлом симейковских таргетов. Например, вот такой незамысловатый скрипт:
    cmake_minimum_required(VERSION 3.5)
    find_package(Boost COMPONENTS system filesystem thread REQUIRED)
    add_library (mylib mysource.cpp)
    target_link_libraries(mylib
    	PRIVATE
    		Boost::system
    		Boost::filesystem
    		Boost::thread
    )
    
    install(TARGETS mylib EXPORT mylib_export)
    export(EXPORT mylib_export FILE cmake/mylib-targets.cmake)

    сгенерирует в поддиректории cmake в директории сборки файл mylib-targets.cmake, где помимо прочего будет следующая любопытная информация:
    # Create imported target mylib
    add_library(mylib STATIC IMPORTED)
    
    set_target_properties(mylib PROPERTIES
      INTERFACE_LINK_LIBRARIES "\$<LINK_ONLY:Boost::system>;\$<LINK_ONLY:Boost::filesystem>;\$<LINK_ONLY:Boost::thread>"
    )


    Таким образом, Симейк сообщает потребителям библиотеки mylib, что при линковке с ней нужно ещё добавить бустовские таргеты. Причём благодаря LINK_ONLY это коснётся только процесса линковки, в целом зависимость от библиотек буста будет приватной, как и указано в скрипте. Если поменять PRIVATE на PUBLIC и сделать тем самым зависимость от буста публичной, то LINK_ONLY уйдёт и будет обычное перечисление интерфейсных зависимостей таргета:
    # Create imported target mylib
    add_library(mylib STATIC IMPORTED)
    
    set_target_properties(mylib PROPERTIES
      INTERFACE_LINK_LIBRARIES "Boost::system;Boost::filesystem;Boost::thread"
    )


    Вам остаётся лишь добавить генерацию и установку тривиального конфига (где будет только find_package для буста и инклуд сгенерированного mylib-targets.cmake) и в потребителях делать find_package(mylib). Всё это кроссплатформенно и является стандартной практикой, не делайте лишних извращений со слиянием статических библиотек.
    Ответ написан
    Комментировать
  • Что не даёт на C++ писать кроссплатформенные приложения?

    Nipheris
    @Nipheris Куратор тега C++
    • прикладное API различных операционных систем - разное. Если бы API было полностью одинаковое, то тогда операционные системы отличались бы только UX, набором софта и утилит, т.е. вместо Linux/Windows/BSD мы бы имели только Linux в разных дистрибуциях или только Windows в разных дистрибуциях. Ну т.е. по сути одну операционную систему, т.к. раз мы сейчас говорим о разработке прикладного софта, то нас интересует прежде всего API для прикладных приложений;
    • т.к. API различных ОС отличается, требуется создание уровней абстракции, которые нивелируют эти различия. В других ответах уже достаточно примеров, я бы вспомнил например о разделителях в именах файлов;
    • дополнительные уровни абстракции нередко сокращают доступное API, т.к. в большинстве случаев невозможно реализовать самому то, что нет в API какой-то из интересующих ОС. Следовательно, приходится оставлять только те интерфейсы, которые так или иначе есть везде;
    • т.к. абстрагированные интерфейсы из пред. пункта более аскетичны, ими сложнее пользоваться, они дают не все возможности, соотв. какие-то задачи уже нецелесообразно решать кроссплатформенным кодом на базе этих асбтрагированных интерфейсов, проще написать несколько вариантов для разных ОС;
    • оба предыдущих пункта - как достаточно успешные попытки сделать абстрагированные интерфейсы, так и наоборот, написание платформозависимого кода для каждой нужной платформы - удорожают разработку. Везёт только в случаях, когда абстрагированные интерфейсы уже есть и достаточно хорошо выполняют свою задачу, как например Asio. Или хорошие кроссплатформенные стандартые API вроде OpenGL, что делает возможным писать кроссплафторменные игры.
    • разработчику ПО не нужно удорожание разработки там, где это не принесёт ощутимой выгоды.
    Ответ написан
    Комментировать
  • Какую библиотеку выбрать для создания GUI-приложений?

    Nipheris
    @Nipheris Куратор тега C++
    Ничего не имею против GTK, но для серьезных приложений с будущей поддержкой - Qt. С будущим у него все нормально. Если отбросить вопрос сложности языка (C++ против Java/C#), то на сегодняшний день я бы порекомендовал его даже для Windows-only приложений.
    Сейчас очень интересно выглядят современные наработки, такие как Qt Quick.
    Ответ написан
    4 комментария