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 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.