I tried to find the answer in the documentation but I could not.
I am new in gRPC and proto files and maybe is very basic question, sorry for that.
I have two files at same directory level
- mainProto.proto
- importedProto.proto
the main proto includes the options
option csharp_namespace = "business.products.accounts";
option go_package = "protobuf/com/bbva/business.accounts;products";
option java_multiple_files = true;
option java_package = "com.bbva.business.products.accounts";
And the importedProto does not have options. They are at same package.
Do I need declare the same options in imported proto ??
Again sorry this is a basic question but I could not find the answer and logic tells me not because are in same package but if another package includes it it will inherit the options from the other main proto buf ? or each protofile can have different options ?
Options only apply to the file/message/field/service/rpc they are placed within. So the options at the top-level of a file only apply to the file, not the package. You need to repeat the options for each file.
Protoc can generate code for a single file at a time. If one file's options could impact another that would mean you'd get different results depending on which files you generate together in a single invocation of protoc. To address that, protoc would have to require that all protos within a package are generated at a time, which isn't the case. Protoc is much more akin to C/C++ where each file may be compiled separately and the package is just a namespacing mechanism.
Related
In bitbake, are inheritances transferable between include files when they are added with require keyword? Or do we need to reuse inherit keyword over and over again in each of the include files? I'm using bitbake to built images with Yocto.
exampleA.inc file
inherit exampleC
exampleB.inc file
require exampleA.inc
In that case, if I want exampleB.inc to be inherited from exampleC as well, do I need to specify it in this file?
Assume that the exampleC is a bbclass file.
TLDR: one inherit statement is enough.
require and include just insert the content of the specified file at the current position in the recipe. This results in the same outcome, as if you had written the whole content of your .inc file into the recipe. Multiple layers of include / require should not change that. This means, that not the .inc file inherits from exanpleC, but rather the recipe, which requires said .inc file.
I also ran some quick tests to confirm the theory, and it all seems to work.
Do not be deterred by the BitBake documentation stating:
[...] you can use the inherit directive to inherit the functionality of a class (.bbclass). BitBake only supports this directive when used within recipe and class files (i.e. .bb and .bbclass).
This does not mean, that it does not work in .inc files, but rather that it will not work for configuration files.
import "google/protobuf/duration.proto";
For the above import statement, I wonder how protoc knows where to find that proto file, since it's obviously not in somewhere of my proto_path.
I have a shared.proto in some package, and could be refered by many projects, so I cannot put it to some project level to share the same protp_path. My question is how to refer this proto just like import duration.proto?
This is a good question for me because I know why it works but (still) don't fully understand how.
Why? Because the well-known types are bundled with protoc in a lib folder alongside the bin folder. I assume for e.g. Python, the implementation similarly includes these.
How? I think (!?) this works because protoc is configured (!?) to look for these types in that location (where is protoc? Look for lib in a sibling folder).
The documentation would benefit from explaining this because I used to manually add these to proto_path until once, when I didn't and worked without the import.
When I create a new project in STM32CubeIDE with the use of a configuration (.ioc) file, configure peripherals, and generate code, all handlers (such as I2C_HandleTypeDef, UART_HandleTypeDef, QSPI_HandleTypeDef, DMA_HandleTypeDef, etc.) and their initialization functions are placed in main.c file.
Instead, is there a way to automatically split the code into multiple pairs of headers and source files (let's say, a header-source pair for UART, a header-source pair for I2C, etc.)?
I would like to define some custom parameters and functions related to my peripherals. Of course, I can create additional headers and source files. But I would prefer to group them all together without producing multiple files. It would simplify the maintenance of a code base.
Thank you.
Yes, it is possible.
As one community member replied to me on ST's forum, to do so, one would need to open their project, .ioc file, go to Project Manager >>> Code Generator, and select "Generate peripheral initialization as a pair of '.c/.h' files per peripheral".
Erlang's -import() directive lets you import code from other modules. Its include() directive lets you import code from headers. Why reasons are there to prefer either one over the other?
My hunch is that headers are good for short, easy-on-the-compiler kinds of code, such as record definitions, when you don't want to have to qualify the
Learn You Some Erlang states[1] that "Erlang header files are pretty similar to their C counter-part: they're nothing but a snippet of code that gets added to the module as if it were written there in the first place." Thus inclusion seems to cause the compiler to duplicate effort across different modules. And header files are what appear to be an optional complication on top of the mandatory module system. So why would I ever use a header file?
[1] https://learnyousomeerlang.com/a-short-visit-to-common-data-structures
Erlang's -import just allows you to call imported functions without the Module. It hurts legibility and should not be used: You need to check the import directive to know whether a function is local or external to the module.
With header files you get the same functionality as in C, you can use them to share -record definitions instead of having a dto-like module (1), you can use them to include -defines to use the same macros (2).
1:
-record(position, {x, y}).
Imagine that you have #position{} throughout the code, instead of defining the record everywhere and updating all of the copies when the record definition changes, you use a header (or a dto module with opaque types, but that's for another question).
And let's just hope that you remember to update all the copies, otherwise chaos ensues.
2:
-define(ENUM01, enum01).
-define(DEFAULT_TIMEOUT, 1000).
Instead of using enum01 and 1000 everywhere, which is error prone and requires multiple updates if you need to change them, you define them in a header and use them as ?ENUM01 and ?DEFAULT_TIMEOUT
Or you can be more thorough when testing:
-ifdef(TEST).
-define(assert(A), true = A).
-else
-define(assert(A), A).
-endif.
Or you can include some useful information:
-define(LOG(Level, X), logger:log(Level, X, #{line => ?LINE}).
The Erlang standard library uses header files to provide the ability to add metadata to your code.
For instance, EUnit functionality:
-include_lib("eunit/include/eunit.hrl").
import is helpful in building encapsulations, whereas include is kind of pre-processing(which means code will be part of the unit before it gets through the compiler).
An import ensues a dependency between two modules, which means a module A importing module B has B as dependency ... Whereas an include is extensional which means a module has included some code and that code is part of the module itself, and that is what header files do.
module(s) and header(s) are 2 semantically different things and serve different purposes. With modules, we can build abstractions by using the export(s), keep things confined by not exporting them, import from other modules(but they are not exported by default), re-export imported things etc etc. So when we import stuff, we can call upon functions from the other module, but only those which are exported in the other module. However that is not the case with header files. Everything inside a header file becomes part of the module which includes them. There is no sense of export/import inside header files. And header files are quite useful for writing and distributing definition(s) which otherwise could lead to redundancy in case of large programs.
So essentially they are 2 different things, so 2 different keywords available at our disposal. So don't prefer one over the other. Learn both of them as we need both of them.
I have a legacy java project that we have been moving to buildr/artifactory from ant/jars in svn.
The primary code is in the default (src/main/java) folder, but we have a few external source paths, for various tests that we can't move into the default folder, but we want to have access with it.
Currently, when adding a new library/regenerating IDE fields, it does not pick up these source paths, and I can't find a succinct discussion in the buildr manual for how to actually add them, rather than re-adding everything manually in eclipse (which just gets wiped out on the next regen).
Any idea how to have multiple source paths get picked up explicitly by buildr so that the idea/eclipse targets generate properly?
There are two ways that I know will work with IDEA. The second one might also work with Eclipse, while the first is specific to the idea task.
The IDEA-specific solution:
define 'proj' do
# ...
iml.main_source_directories << _('src/other')
end
iml also has test_source_directories and excluded_directories arrays you can append to.
The possibly eclipse-compatible solution, with more background than you probably want:
The iml object gets its default values for the main and test source directory arrays from project.compile.sources and project.test.compile.sources (slight simplification; resources are considered also). Buildr defines these .sources project attributes from the layout, so instead of explicitly appending to the iml attributes, you could use a custom layout for your project that includes your special source paths. That might work with the eclipse task, but I haven't tried it.