CMake идиома для преодоления странности файловой системы libstdc ++? - PullRequest
Новая
       33

CMake идиома для преодоления странности файловой системы libstdc ++?

1 голос
/ 03 февраля 2020

Если вы строите код C ++ 14 с помощью G ++ и libstdc ++, есть библиотека с именем libstdc++fs, которая отделена от остальной части libstdc++ и содержит код для std::experimental::filesystem. Если вы не будете ссылаться на него, вы получите неопределенные ссылки.

«Уловка», которую я использую для преодоления этого сейчас: 

if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
        set(CXX_FILESYSTEM_LIBRARIES "stdc++fs")
endif()

и позже: 

target_link_libraries(my_target PUBLIC ${CXX_FILESYSTEM_LIBRARIES})

но - мне не нравится помещать этот код в каждый проект, над которым я работаю. Есть ли более простая или более стандартная идиома, которую я мог бы использовать? Каким-то образом это может произойти неявным образом, возможно, с каким-то тайным замаскированным CMake c?

1 Ответ

1 голос
/ 03 февраля 2020

tl; dr: Ничего прямо сейчас, ждите более новую версию CMake

Как любезно указывает @Pedro, это известная проблема, и открыто выдайте об этом на сайте KitWare GitLab для CMake:

Переносимые ссылки для C ++ 17 std :: filesystem

При использовании CMAKE_CXX_STANDARD=17 и std::filesystem, G CC требует связывания дополнительной библиотеки: stdc++fs. ... Если включен C ++ 17, стоит ли автоматически ссылаться на stdc ++ fs для версий G CC, для которых это требуется? Точно так же для любых причуд в других компиляторах или библиотеках.

Проблема KitWare касается C ++ 17, для которого, очевидно, вам все еще нужна отдельная дополнительная библиотека (т.е. это не только из-за "экспериментальности") в C ++ 14). Надеюсь, мы увидим некоторую тягу в этом вопросе - но

Примечание: Если у вас возникла эта проблема с std::filesystem, you're in luck - that code is built into libstdc ++ `в C ++ 17, начиная с G CC 9, так что если вы используя g ++ 9 или новее и std :: filesystem, вы больше не должны сталкиваться с этой проблемой.

...