You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current generation code is unfortunately an unmaintainable mess. I had no idea when I started writing it how many parameter types and variations there were. Nor did I understand how many of the permutations would need to be handled. As a result I can't see a way to migrate the current code to a better place. I'd normally prefer to iteratively refactor code to improve it, but in this case I don't think that it's practical.
The generated code is also problematic in that it's very slow to build. This is mostly because of the extensive use of cgo. It's in every wrapping function, and there are many generated C functions for callbacks. This makes development of gobbi painful, with continuous rounds of code generation and slow builds.
It's difficult to move forward with the code as it is. Issues #16 and #17 are examples of cases where I struggle to work with the existing generation code.
I am looking at re-writing to use girepository for invocation of library functions.
Pros
the generated functions that wrap library functions will be become simpler, and will not contain any cgo code
the code that generates the wrapper functions will be simpler
all cgo code will be in one or two internal packages
all of the complexity of the multitude of parameter types and variations will be in here
all of the marshalling of parameters between Go types and C types will be in here
all of code dealing with transfer of ownership will be in here
much of the code will be amenable to unit testing
building will be much quicker
Cons
there will be a small overhead on function calls
unavailabilty of a library function (for example running an application on a system with older than required version of a library) will not be detected until it is first called
Initial work is proving promising. It will be at least several more weeks before it's in a reasonably useable state.
The text was updated successfully, but these errors were encountered:
The current generation code is unfortunately an unmaintainable mess. I had no idea when I started writing it how many parameter types and variations there were. Nor did I understand how many of the permutations would need to be handled. As a result I can't see a way to migrate the current code to a better place. I'd normally prefer to iteratively refactor code to improve it, but in this case I don't think that it's practical.
The generated code is also problematic in that it's very slow to build. This is mostly because of the extensive use of cgo. It's in every wrapping function, and there are many generated C functions for callbacks. This makes development of gobbi painful, with continuous rounds of code generation and slow builds.
It's difficult to move forward with the code as it is. Issues #16 and #17 are examples of cases where I struggle to work with the existing generation code.
I am looking at re-writing to use girepository for invocation of library functions.
Pros
Cons
Initial work is proving promising. It will be at least several more weeks before it's in a reasonably useable state.
The text was updated successfully, but these errors were encountered: