Ха-ха) ох уж этот Т9

Вакансии через @AlexFails в отдельный канал, пожалуйста. Читайте правилап чата.

Извините

Ха-ха) ох уж этот Т9

Конееечно.)

Сам канал: https://t.me/ProCxxJobs

Окей, а если потребовалось отлаживать посылки через логический анализатор. Тоже будешь пользоваться документацией либы? :)

ну это чутка другое же

Вот как знал...

я даже видел как ты напрягся., чтоыб сразу удалить сообщение. Когда там уже концепты везде?

я даже видел как ты напрягся., чтоыб сразу удалить сообщение. Когда там уже концепты везде?

Ну, как в компили впилят, пожалуй...

ну это чутка другое же

Эмбед же, как иначе может? Не все проблемы ты документацией решаешь, иногда думать ещё нужно.

Эмбед же, как иначе может? Не все проблемы ты документацией решаешь, иногда думать ещё нужно.

это да...

Ну, как в компили впилят, пожалуй...

оно вроде уже в гцц есть, но либу с готовыми концептами ещё не подвезли

Вот как знал...

требую такой варнинг во все компиляторы!

оно вроде уже в гцц есть, но либу с готовыми концептами ещё не подвезли

Эх... а у нас все больше разговоры про то, когда новые ISA впилят в компилятор

Про стандарт и фичи как-то в бекграунде только

Данные не передовались, например я отправлял рандомные значени, и они не читались ...

Открой через screen /dev/ttyS0 с двух сторон и проверь что рандомные буковки которые ты печатаешь передаются

Открой через screen /dev/ttyS0 с двух сторон и проверь что рандомные буковки которые ты печатаешь передаются

не знаю как там в линуксе, но ты не можешь открыть один и тот же com порт с двух приложений

не знаю как там в линуксе, но ты не можешь открыть один и тот же com порт с двух приложений

А он мобдас сам себе передает?

У тебя два устройства

На одном открой screen

И на другом открой screen

У него же два распбери пая

Причем тут два приложения вообще, он на разных машинах

Причем тут два приложения вообще, он на разных машинах

алле > Открой через screen /dev/ttyS0 с двух сторон и проверь что рандомные буковки которые ты печатаешь передаются и как это понимать? по мне так это типа открыть ttyS0 через 2 приложения...

Есть две Raspberry Pi, и нужно обмениваться данными, у меня получилось сделать это только по TCP, а нужно по RTU (это как бы поверх UART, если я не ошибаюсь, просто с этой либой недавно начал разбираться), может есть какие нибудь примеры на cpp, может кто-нибудь ссылку на инфу нормальную кинет )

алле > Открой через screen /dev/ttyS0 с двух сторон и проверь что рандомные буковки которые ты печатаешь передаются и как это понимать? по мне так это типа открыть ttyS0 через 2 приложения...

ssh raspberry_pi_1 screen /dev/ttyS0 115200 ssh raspberry_pi_2 screen /dev/ttyS0 115200

ssh raspberry_pi_1 screen /dev/ttyS0 115200 ssh raspberry_pi_2 screen /dev/ttyS0 115200

а на одной машине?

В многозадачных операционных системах можно иметь два окошка консоли на одной машине

В чем проблема?

поцоны, я хочу на линукс системе иметь две версии glibc, при компиляции у конкретного приложения через: -Wl,--rpath=/opt/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 задавать использование специальных версий либ. Как мне задать это: -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 через cmake? Все что нашел - мертвое обсуждение https://cmake.org/Bug/view.php?id=15699

не знаю как там в линуксе, но ты не можешь открыть один и тот же com порт с двух приложений

в линуксе можешь, но можно и в эксклюзивном режиме открывать

в линуксе можешь, но можно и в эксклюзивном режиме открывать

?

поцоны, я хочу на линукс системе иметь две версии glibc, при компиляции у конкретного приложения через: -Wl,--rpath=/opt/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 задавать использование специальных версий либ. Как мне задать это: -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 через cmake? Все что нашел - мертвое обсуждение https://cmake.org/Bug/view.php?id=15699

эм, LINK_FLAGS? или не работает?

эм, LINK_FLAGS? или не работает?

CMAKE_EXE_LINKER_FLAGS?

CMAKE_EXE_LINKER_FLAGS?

дак я не понял, ты сам себе в итоге ответил?

дак я не понял, ты сам себе в итоге ответил?

пробовал через это - CMAKE_EXE_LINKER_FLAGS, не работало погуглил твой совет - set_target_properties(${TARGET} PROPERTIES LINK_FLAGS "-Wl,--dynamic-linker=/opt/lib/ld-linux.so.3") - так похоже что работает readelf target --headers | grep interp дает: [Requesting program interpreter: /opt/lib/ld-linux.so.3]

поцоны, я хочу на линукс системе иметь две версии glibc, при компиляции у конкретного приложения через: -Wl,--rpath=/opt/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 задавать использование специальных версий либ. Как мне задать это: -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 через cmake? Все что нашел - мертвое обсуждение https://cmake.org/Bug/view.php?id=15699

LINK_FLAGS ?

Или что там в шмейке

я про это не знал, мне уже подсказали, спасибо

можно дальше документацию не читать

>SET_TARGET_PROPERTIES(foo PROPERTIES LINK_FLAGS -Wl,-specialFlag)

Нагуглилось сразу

Есть вопросец по организации CMake таргетов для такой цели: есть проект, в нем есть часть, отвечающая за работу бд. Сам модуль определяет интерфейсы в хэдерах, и есть разные реализации этих хэдеров под разные бд. Этот модуль соответственно используют другие таргеты, и плюс сам экзешник. Причем другие таргеты используют только интерфейсы из хэдеров, а имлементация создается и кидается соответственно в мейне. Так вот, как правильно с точки зрения таргетов и их зависимостей это все организовать с симейке? Вроде бы если только используешь интерфейсный хэдер, то линковать таргет целиком смысла не имеет. Был вариант сделать отдельно таргеты для интерфейсов и для разных бэкендов, в таргетах линковаться к интерфейсам, а в главном таргете уже линковать один из реальных бэкэндов, но вот непонятно насколько это хорошее решение.

я гуглил через cmake set ld-linux, собственно правильный запрос в гугл 90% успеха

Есть вопросец по организации CMake таргетов для такой цели: есть проект, в нем есть часть, отвечающая за работу бд. Сам модуль определяет интерфейсы в хэдерах, и есть разные реализации этих хэдеров под разные бд. Этот модуль соответственно используют другие таргеты, и плюс сам экзешник. Причем другие таргеты используют только интерфейсы из хэдеров, а имлементация создается и кидается соответственно в мейне. Так вот, как правильно с точки зрения таргетов и их зависимостей это все организовать с симейке? Вроде бы если только используешь интерфейсный хэдер, то линковать таргет целиком смысла не имеет. Был вариант сделать отдельно таргеты для интерфейсов и для разных бэкендов, в таргетах линковаться к интерфейсам, а в главном таргете уже линковать один из реальных бэкэндов, но вот непонятно насколько это хорошее решение.

Таргет для хедеров тоже норм

похоже что роботает, под strace посмотрю не лезет ли в /lib и в продакшон

дак зачем strace

ldd тебе все покажет

ldd?

Есть вопросец по организации CMake таргетов для такой цели: есть проект, в нем есть часть, отвечающая за работу бд. Сам модуль определяет интерфейсы в хэдерах, и есть разные реализации этих хэдеров под разные бд. Этот модуль соответственно используют другие таргеты, и плюс сам экзешник. Причем другие таргеты используют только интерфейсы из хэдеров, а имлементация создается и кидается соответственно в мейне. Так вот, как правильно с точки зрения таргетов и их зависимостей это все организовать с симейке? Вроде бы если только используешь интерфейсный хэдер, то линковать таргет целиком смысла не имеет. Был вариант сделать отдельно таргеты для интерфейсов и для разных бэкендов, в таргетах линковаться к интерфейсам, а в главном таргете уже линковать один из реальных бэкэндов, но вот непонятно насколько это хорошее решение.

проблема в том что cmake пока не умеет, делать инклуды, если делаешь target_include... но он их умеет делать если target_lib

ldd?

ldd yourbinary

Хочется избежать мануального прописывания путей где-либо

скрипт такой, поверх ld

понял, спасибо

то есть чтобы не было target_include_directories(B INTERFACE ${CMAKE_SOURCE_DIR}/path/to/libA/interfaces

проблема в том что cmake пока не умеет, делать инклуды, если делаешь target_include... но он их умеет делать если target_lib

Ну, там не как инклюды их надо заворачивать, а как ресурсы, наверное :)

хз как реализовывать правильно, но идея сама валидная

хз как реализовывать правильно, но идея сама валидная

не оч

не оч

Норм, если оправдано

Есть вопросец по организации CMake таргетов для такой цели: есть проект, в нем есть часть, отвечающая за работу бд. Сам модуль определяет интерфейсы в хэдерах, и есть разные реализации этих хэдеров под разные бд. Этот модуль соответственно используют другие таргеты, и плюс сам экзешник. Причем другие таргеты используют только интерфейсы из хэдеров, а имлементация создается и кидается соответственно в мейне. Так вот, как правильно с точки зрения таргетов и их зависимостей это все организовать с симейке? Вроде бы если только используешь интерфейсный хэдер, то линковать таргет целиком смысла не имеет. Был вариант сделать отдельно таргеты для интерфейсов и для разных бэкендов, в таргетах линковаться к интерфейсам, а в главном таргете уже линковать один из реальных бэкэндов, но вот непонятно насколько это хорошее решение.

Я могу ошибаться, но как будто бы получаются куча таргетов db_impl1,...,db_implN, и таргет db_head с интерфейсными хедерами; в либах-модулях где нужно тыкать бд делается target_link_libraries(db_head), а в мейне target_link_libraries(main libA libB db_head db_impl1)

Все так

Ок Вопрос получается в том, насколько это торт?

Самой главной проблемой кмк будет сделать так, чтобы db_head читабельно ругался если его в конечном счете линкуют без реализации Т.е. нужна зависимость "от хотя бы одного из Х", как это сделать в цмаке я не знаю Без этого посыпятся куча непонятных ошибок линковки и ненайденных функций

Насколько распространена практика const pure virtual методов? Руки чешутся сделать такой, но с другой стороны не хочется ограничивать такими требованиями реализацию - ей тогда придётся костылять mutable полями и всё такое

?

https://www.tldp.org/HOWTO/Serial-HOWTO-13.html

у меня прост было пару раз что два экземпляра процесса запусалось по ошибке при отладке, и конкурентно писали/читали из одного порта

читать стандарты - для слабаков, на гитхабе всё есть. так говорил заратустра.

Самой главной проблемой кмк будет сделать так, чтобы db_head читабельно ругался если его в конечном счете линкуют без реализации Т.е. нужна зависимость "от хотя бы одного из Х", как это сделать в цмаке я не знаю Без этого посыпятся куча непонятных ошибок линковки и ненайденных функций

Я просто не вижу других альтернатив

Линковать конкретную реализацию везде и всюду в зависимости от условий

Самой главной проблемой кмк будет сделать так, чтобы db_head читабельно ругался если его в конечном счете линкуют без реализации Т.е. нужна зависимость "от хотя бы одного из Х", как это сделать в цмаке я не знаю Без этого посыпятся куча непонятных ошибок линковки и ненайденных функций

Про линковку разговора не было. Запросто может быть, что в рантайме биндится

Линковать конкретную реализацию везде и всюду в зависимости от условий

Поскольку таргеты статические, то тогда у меня будет каждый таргет прилинкован к куче ненужного кода

Я боюсь оно разлуки размер билд папки тогда

If(linux_server) link(postgresql) elseif(win_server) link(mssql) else error(unsupported) Запихнуть в макрос и пихать везде где не нужно

Поскольку таргеты статические, то тогда у меня будет каждый таргет прилинкован к куче ненужного кода

Емнип, библиотеки в библиотеки не влинковываются до последнего Могу ошибаться

If(linux_server) link(postgresql) elseif(win_server) link(mssql) else error(unsupported) Запихнуть в макрос и пихать везде где не нужно

Везде пихать не хочется, можно внутрь самого таргета засунуть

Плагинами делать

В рантайме переключаться

Обновлять проще

Везде пихать не хочется, можно внутрь самого таргета засунуть

Плюс проблема размера не решается

В рантайме переключаться

А как это решает проблему организации cmake таргетов?

А как это решает проблему организации cmake таргетов?

Линковать не нужно

Даже если все это происходит в рантайме то мне нужно эти таргетов как-то обозначить при компиляции

Линковать не нужно

Почему же?

Потому что dlopen

Все статически линкуется

Есть вопросец по организации CMake таргетов для такой цели: есть проект, в нем есть часть, отвечающая за работу бд. Сам модуль определяет интерфейсы в хэдерах, и есть разные реализации этих хэдеров под разные бд. Этот модуль соответственно используют другие таргеты, и плюс сам экзешник. Причем другие таргеты используют только интерфейсы из хэдеров, а имлементация создается и кидается соответственно в мейне. Так вот, как правильно с точки зрения таргетов и их зависимостей это все организовать с симейке? Вроде бы если только используешь интерфейсный хэдер, то линковать таргет целиком смысла не имеет. Был вариант сделать отдельно таргеты для интерфейсов и для разных бэкендов, в таргетах линковаться к интерфейсам, а в главном таргете уже линковать один из реальных бэкэндов, но вот непонятно насколько это хорошее решение.

нормально про таргеты для интерфейсов и бекендов, их потом собираешь в ехе

Тогда смысла в разделении нет

Тогда смысла в разделении нет

Почему же?

Я не хочу все тащить всегда

Почему же?

Все равно собирать же

А указывать какие имплементации мне вшить в итоговый бинарь

А те которые не нужны я и не собираю

Ну, тут просто таргеты тащить определенные

Это на уровне таргета ращруливаться должно

Ну, тут просто таргеты тащить определенные

Вот и вопрос как это организовать

Плюс проблема размера не решается

мне кажется, если ты делаешь add_library(libA) add_library(libB) target_link_libraries(libA libB), то цмак укажет только зависимости между либами; размер увеличится только когда ты сделаешь target_link_libraries(main libA) - вот тогда он статически слинкует с мейном обе либы

Вот и вопрос как это организовать

Опции семейка не?

Там же есть чотктакое

мне кажется, если ты делаешь add_library(libA) add_library(libB) target_link_libraries(libA libB), то цмак укажет только зависимости между либами; размер увеличится только когда ты сделаешь target_link_libraries(main libA) - вот тогда он статически слинкует с мейном обе либы

Надо проверить на самом деле