4 ms·

There should be binaries for Mac, Windows and Linux and the source should compile on FreeBSD and others. What's missing?

e12e 11y ago
I'm not sure if you gain a lot of confidence from me if you build a package manager in go, and the avoid distributing it using go excellent package manager (ie: "go get qpm.io/qpm", done)... ;-) If you will pardon me from being lazy and not looking at the source, is there a reason for that? I see a lot of people here don't seem to get the purpose of this -- having played a bit with c++ and pkg-config[1] ... I assume that pkg-config is the kind of software this project tries to improve on? I can see how that might make sense for qt, which already has some properties of a runtime/standard-library (eg: qt string). And/or perhaps copy go's package management for c++/qt? I suppose I can't really say I've seen the need that this project fills -- but I still wish it well :-) [1] https://www.freedesktop.org/wiki/Software/pkg-config/ https://www.freedesktop.org/wiki/Software/pkg-config/
- jrbarron 11y ago
  Very valid point about 'go get'! The main problem currently is that we put all the source dependencies in the repo as Git submodules and use the repo itself as the GOPATH. We do this because we are using some dependencies whose APIs are still changing often (eg: Protobuf/GRPC) and we wanted control over the exact SHA1 we were using. Now that the vendoring experiment is enabled in Go 1.6, we can probably use that to solve this. Thanks for bringing this up! As for the problem this solves; this is a package manager for Qt app development. It doesn't try to operate on a system level like pkgconfig. There's no system-wide shared code. Every app you are building has it's own copy of the code it needs locally like npm/node_modules. In addition to downloading dependencies, the tool generates some code to cleanly add it to your project without you having to mess with include paths or other settings. It also encourages things like proper namespacing (both C++ and QML) to avoid collisions.
akerro 11y ago
I don't want to install Go to compile your tool to compile other tools to compile my tool. Pretty much that.
- jrbarron 11y ago
  Understandable :) Can I ask what platform you are on?
  - akerro 10y ago
    FreeBSD 32bit and ArchLinux 64

e12e 11y ago

I'm not sure if you gain a lot of confidence from me if you build a package manager in go, and the avoid distributing it using go excellent package manager (ie: "go get qpm.io/qpm", done)... ;-) If you will pardon me from being lazy and not looking at the source, is there a reason for that? I see a lot of people here don't seem to get the purpose of this -- having played a bit with c++ and pkg-config[1] ... I assume that pkg-config is the kind of software this project tries to improve on? I can see how that might make sense for qt, which already has some properties of a runtime/standard-library (eg: qt string). And/or perhaps copy go's package management for c++/qt? I suppose I can't really say I've seen the need that this project fills -- but I still wish it well :-) [1] https://www.freedesktop.org/wiki/Software/pkg-config/ https://www.freedesktop.org/wiki/Software/pkg-config/

jrbarron 11y ago
Very valid point about 'go get'! The main problem currently is that we put all the source dependencies in the repo as Git submodules and use the repo itself as the GOPATH. We do this because we are using some dependencies whose APIs are still changing often (eg: Protobuf/GRPC) and we wanted control over the exact SHA1 we were using. Now that the vendoring experiment is enabled in Go 1.6, we can probably use that to solve this. Thanks for bringing this up! As for the problem this solves; this is a package manager for Qt app development. It doesn't try to operate on a system level like pkgconfig. There's no system-wide shared code. Every app you are building has it's own copy of the code it needs locally like npm/node_modules. In addition to downloading dependencies, the tool generates some code to cleanly add it to your project without you having to mess with include paths or other settings. It also encourages things like proper namespacing (both C++ and QML) to avoid collisions.

akerro 11y ago

I don't want to install Go to compile your tool to compile other tools to compile my tool. Pretty much that.

jrbarron 11y ago
Understandable :) Can I ask what platform you are on?
- akerro 10y ago
  FreeBSD 32bit and ArchLinux 64