|
|
|
|
|
|
by mappu
615 days ago
|
|
|
The main rationale is definitely the license. The existing bindings for Qt Widgets (therecipe/qt and kitech/qt.go) are LGPL. That's just really difficult to use in Go where static linking is the default behaviour. The other bindings have some strange behaviours when I checked them closely. - therecipe/qt: The design of the "qtbox" runtime for therecipe/qt, introduced before the maintainer went MIA. Now that we know the Jia Tan xz story, it's my hope that MIQT can be a "nothing up my sleeve" binding with a clear source code supply chain, with no prebuilt binaries. - kitech/qt.go: The rationale for their version was to focus on compilation speed, but with GOCACHE this is no longer really a problem. It also seems to be unmaintained. |
|
|
You can have the LGPL'ed code but the price to pay is that your users give your objects files (i.e. pre-link stuff; but not the source code) so that your users can modify the LGPL code and rebuild your project with the modifications.
Moreover: https://pkg.go.dev/cmd/link
So it seems that you can have access to the object files.
Overall, it is possible to make your bindings LGPL. I understand this is a bit trickier and not very user friendly.
Or you could dual license.
But well, it's a political choice, so I won't try to convince you :-)