4 ms·

author here; The size depends on your platform and the way you build it. If you used `qtdeploy` instead of `go run/build`, you should get a 2mb binary which inc

author here; The size depends on your platform and the way you build it. If you used `qtdeploy` instead of `go run/build`, you should get a 2mb binary which includes Go's runtime + only the needed Qt C++ code. (A normal go binary has the size of 1.5mb or so) The rest are Qt dynamic libs, which are not all needed, depending on what you build. You can safely remove plugins and maybe whole modules. edit: and you can also compile Qt on your own to strip out ICU and other unnecessary stuff + with Qt 5.8 things will get even more lightweight.

JepZ 10y ago
hehe, thx for the quick reply. Had some trouble with qtdeploy and since go build worked (and I prefer go build workflow wise) I assumed it would result in the same binary. The demo application works without any of the libs from the deploy folder, but thats probably because it uses the system libs. So cool: - Option 1: 'go build' creates one large 50mb binary - Option 2: 'qtdeploy' creates a bundle with a little more than whats required but you can remove what you dont need - Option 3: just takes the binary and let the system provide the libs Super cool would be, if that downsizing could be made automatically but since that icu stuff takes alone 24mb, that might be difficult. Anyway, great work. Spend half a day to get it working with system libs, but in the end I had to learn to just follow the tutorial and download qt again. Great job :-)
- therecipe 10y ago
  Thank you :) I should probably mention that Option 1 is still depending on all the system/dynamic libs. And therefore only usefull to save time during development or if you need more control about the build. If you want to get a smaller binary, run `qtminimal` and `go build/run -tags=minimal` to include only the necessary C++ code, but the binary will still depend on the dynamic/system libs. I will add full statically linking in the future, but probably only after Qt 5.8 is released.
bostik 10y ago
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.
- therecipe 10y ago
  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
  - bostik 10y ago
    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.
    - therecipe 10y ago
      Mh, usually the minimal_cgo_* files and the cgo_* files should use the same imports. But the qtsetup won't always re-generate these cgo_* files if the QT_DIR is up to date (there is probably a bug if you use QT_PKG_CONFIG). So I would use `qtminimal` or `qtdeploy` for debugging this, because the minimal_cgo_* files are always re-generate. And you may also want to change `InfoLevel` in `internal/utils/logger.go` to `DebugLevel` and then re-build the cmd/tools to get additional infos. Hope this helps :)

JepZ 10y ago

hehe, thx for the quick reply. Had some trouble with qtdeploy and since go build worked (and I prefer go build workflow wise) I assumed it would result in the same binary. The demo application works without any of the libs from the deploy folder, but thats probably because it uses the system libs. So cool: - Option 1: 'go build' creates one large 50mb binary - Option 2: 'qtdeploy' creates a bundle with a little more than whats required but you can remove what you dont need - Option 3: just takes the binary and let the system provide the libs Super cool would be, if that downsizing could be made automatically but since that icu stuff takes alone 24mb, that might be difficult. Anyway, great work. Spend half a day to get it working with system libs, but in the end I had to learn to just follow the tutorial and download qt again. Great job :-)

therecipe 10y ago
Thank you :) I should probably mention that Option 1 is still depending on all the system/dynamic libs. And therefore only usefull to save time during development or if you need more control about the build. If you want to get a smaller binary, run `qtminimal` and `go build/run -tags=minimal` to include only the necessary C++ code, but the binary will still depend on the dynamic/system libs. I will add full statically linking in the future, but probably only after Qt 5.8 is released.

bostik 10y ago

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.

therecipe 10y ago
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
- bostik 10y ago
  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.
  - therecipe 10y ago
    Mh, usually the minimal_cgo_* files and the cgo_* files should use the same imports. But the qtsetup won't always re-generate these cgo_* files if the QT_DIR is up to date (there is probably a bug if you use QT_PKG_CONFIG). So I would use `qtminimal` or `qtdeploy` for debugging this, because the minimal_cgo_* files are always re-generate. And you may also want to change `InfoLevel` in `internal/utils/logger.go` to `DebugLevel` and then re-build the cmd/tools to get additional infos. Hope this helps :)