Add BUILD files for printf and bsw libraries

[SuhashiniNaik]

Add BUILD files for printf and bsw libraries

• //libs/3rdparty/printf:printf
• //libs/bsw/asyncConsole:async_console
• //libs/bsw/cpp2can:cpp2can
• //libs/bsw/cpp2ethernet:cpp2ethernet
• //libs/bsw/lifecycle:lifecycle

Printf BUILD.bazel added to .riminfo

[christophruethingbmw]

Looks good to me, just a small comment.

[christophruethingbmw]

How does the copts interact with the options of depending libraries? Let's say we have a cc_library printf_user and it uses a deps = ["//libs/3rdparty/printf"], then all files within printf_user will be compiled with these additional flags, right? What in case we compile globally with a different -stc? Or with differend error flags?

Is there at all a reason that we need to put these extra warning flags and the std in the first place?

The -I is just there to allow the printf_config.h generated by the expand_template above to be in the include path, right? The strip_include_prefix does not help for it and includes would lead to system includes, right? Or do we even want this to be a system include?

[DominikAFischer]

How does the copts interact with the options of depending libraries? Let's say we have a cc_library printf_user and it uses a deps = ["//libs/3rdparty/printf"], then all files within printf_user will be compiled with these additional flags, right? What in case we compile globally with a different -stc? Or with differend error flags?

The copts flags are not propagated to consumers t all and should only affect printf itself.

Is there at all a reason that we need to put these extra warning flags and the std in the first place?

These flags are applied like this also on the Cmake side:

• https://github.com/eclipse-openbsw/openbsw/blob/main/libs/3rdparty/printf/CMakeLists.txt#L72-L73
• https://github.com/eclipse-openbsw/openbsw/blob/main/libs/3rdparty/printf/CMakeLists.txt#L93

The -I is just there to allow the printf_config.h generated by the expand_template above to be in the include path, right? The strip_include_prefix does not help for it and includes would lead to system includes, right? Or do we even want this to be a system include?

Correct: strip_include_prefix doesn't cover generated files.
includes would cause -iSystem, which might be fine but currently would be a deviation from the Cmake side

[christophruethingbmw]

okay, then let's leave it like this, but still something like -std might also affect the header files which we include somewhere. Since it is like this im CMake as well we can take it over and later adapt it on both sides.