Conversation
Added a plugin_code_generator.py which generates code plugin specific code. The script is called when the cmake command is executed, and generates files in libraries/utilities/include/graphene/utilities/. The generated files look like this: "generated_*file_name_where_the_generated_code_is_included*_*name_for_the_code_part_where_the_code_is_included*.hpp
pmconrad
left a comment
pmconrad
left a comment
There was a problem hiding this comment.
Looks straightforward and simple enough. Can't really comment on the python code itself.
| data_dic = dict() | ||
| data_dic['plugin_name'] = parsed_data['plugin_name'] | ||
| data_dic['plugin_namespace'] = parsed_data['plugin_namespace'] | ||
| data_dic['plugin_project'] = parsed_data['plugin_project'] |
There was a problem hiding this comment.
I'm not a python expert - is it really necessary to copy the fields instead of appending parsed_data directly?
There was a problem hiding this comment.
Yeah it would be possible to iterate inside there. But my thought was, we don't have much data hence the speed isn't really necessary here. And like this it's just better separated.
| # libraries/app/api.cpp | ||
| # libraries/app/application.cpp | ||
|
|
||
| generated_files_root_dir = "libraries/utilities/include/graphene/utilities/" |
There was a problem hiding this comment.
The generated files are not really headers (except generated_api_hpp_include_code.hpp maybe), therefore they shouldn't be put into the include directory. Also don't use .hpp for them, perhaps .hxx or .cxx depending on content.
There was a problem hiding this comment.
Will change that for more clearance.
But generally would you say this is way of solving this issue? I think it looks kinda weird to do includes in the middle of the code. But I heard in some projects this is common. Still wouldn't call it good practice.
There was a problem hiding this comment.
Well, I wouldn't call it beautiful. :-)
But if it gets the job done it's ok I guess.
2 participants
code generator for plugin related code