First of all, thank you. The effort of maintaining Qt in any way or form is ... nontrivial.
I've wanted to try this one out, but it looks like I'm maybe trying something too far off from mainstream. I like how the bindings can be built against incomplete Qt releases (iow. just the development packages available in debian sid); the build complains when some modules can't be found but continues nonetheless. Sure, it takes QT_DIR and PKG_CONFIG settings to build like this but I have no problem there.
So far I haven't found a way to build even the sample project against this type of custom build though. I'll try to find more time to dive in as to why this happens but I'm sure this is an error on my end. Once I figure that out, I should be able to provide a documentation update.
As to why? I have an old project which I need to revive, and being stuck in ancient GTK land with dubious bindings and even more dubious upstream practices sounds less appealing than porting things over.
Did you tried to use QT_MISC_DIR (which should contains the "mkspecs" subfolder) and QT_DOC_DIR, which should contain for example (QtCore/qtcore.index)?
Or if you like, open an issue on github and we can try to sort this out :) edit: also if you use PKG_CONFIG=true, the QT_DIR will be ignored
Hum, I hadn't, but in retrospect I should have. I've done my share of Qt builds in the past and mkspecs path was often an amusing detail. Didn't solve the problem though.
But I think I found out at least one thing that goes wrong. I'll provide a github issue report later this weekend but here's the short version:
* The generated #cgo directives for CXXFLAGS are different for desktop and minimal files. Minimal is generated with -I$(QT_INCLUDE_DIR)/QtFoo include paths; desktop is generated with -I$(QT_DIR)/<major.minor>/gcc_64/include/QtFoo paths instead. So headers in desktop build are looked up from library directory paths (and with obviously bad path elements too).
* When building, qtsetup goes for desktop target.
More data coming in via github once I get the exact details sorted out.
I've wanted to try this one out, but it looks like I'm maybe trying something too far off from mainstream. I like how the bindings can be built against incomplete Qt releases (iow. just the development packages available in debian sid); the build complains when some modules can't be found but continues nonetheless. Sure, it takes QT_DIR and PKG_CONFIG settings to build like this but I have no problem there.
So far I haven't found a way to build even the sample project against this type of custom build though. I'll try to find more time to dive in as to why this happens but I'm sure this is an error on my end. Once I figure that out, I should be able to provide a documentation update.
As to why? I have an old project which I need to revive, and being stuck in ancient GTK land with dubious bindings and even more dubious upstream practices sounds less appealing than porting things over.