VM
248 macro_ensure_version("4.0.0" "${_gcc_version}" GCC_IS_NEWER_THAN_4_0)
249 macro_ensure_version("4.1.0" "${_gcc_version}" GCC_IS_NEWER_THAN_4_1)
250 macro_ensure_version("4.2.0" "${_gcc_version}" GCC_IS_NEWER_THAN_4_2)Size: a a a
2020 October 19
VM
по-моему, в 2020 gcc<=4 можно найти только в МСВС каком-нибудь, разве что
ВП
а сами майтейнеры исходников что думают ? или давно уже забили на свою поделку ?
VM
а сами майтейнеры исходников что думают ? или давно уже забили на свою поделку ?
sci-chemistry/openbabelВП
может просто версию 3.1.1 openbabel взять ? зачем старую палочкой трогать ? - думаю старой версии пора уже в компост
ВП
в арче тривиальный сценарий сборки 2020 года для 3.1.1 и на cmake к тому же
ВП
поломалась у меня сборка qtwebengine на питон 3.9, снова перечитываю руководство к действию https://github.com/freebsd/freebsd-ports-kde/blob/webengine-python3/www/qt5-webengine/files/python3-build.md
кстати пофиксил, проблема схожая примерно как и в случае openbabel, при переходе с python 3.8.6 на 3.9.0 приключилась :)
VM
VM
в оригинале там вообще [345] в регексе
VM
это мейнтейнер, лопух, патчи таки енакладывает
VM
один для gcc 6 и 7, который добавляет в регекс 6 и 7, а второй - 8 и 9
VM
нет чтобы сразу нормально пропатчить одним патчем, упорок
ВП
каких только чудес в мире не бывает
VM
string(REGEX MATCH "[0-9]*\\.[0-9]\\.[0-9]" _gcc_version "${_gcc_version_info}")VM
я, вот, правда, не уверен, что CMake понимает регекс так же как греп
VM
и что на <10 оно тоже правильно сработает
ВП
может просто по точкам разделить ?
VM
мало ли он там точек найдёт в выводе версии компилятора :)