Open ddevault opened 4 years ago
That's an interesting thought. I wasn't aware of the --modversion
flag. However after a little bit of playing with a script, I'm not sure that it'll be easy to use it.
gobbi generates versioned files determined from version
attributes in gir files. A version
attribute's value is the library version when an api was introduced. gobbi finds all of the distinct version values present for a library. It then generates a file for each one, along with a file for apis present in all versions.
lib/somelib/v-.go apis present in all versions
lib/somelib/v-2.18.go apis present in 2.18 and later
lib/somelib/v-2.20.go apis present in 2.20 and later
lib/somelib/v-2.20.3.go apis present in 2.20.3 and later
lib/somelib/v-2.22.go apis present in 2.22 and later
Perhaps I have version 2.20.5 of somelib installed. Because no new apis were introduced in version 2.20.5 there will have been no mention of it in the gir file. So no file will have been generated corresponding to that version. And no build tag will exist for version 3.20.5.
If pkg-config --modversion
is used to generate a build tag somelib_2.20.5
, it will not correspond to any build tag for somelib. And so no file from lib/somelib
will be used by go build
.
For example I have gtk 3.22.30 installed, and there's no reference to this version in Gtk-3.0.gir
.
And of course one may wish to build targetting earlier versions of libraries than those installed locally.
You can just cut off the last number. pkg-config --modversion gobject-2.0 | cut -d. -f1-2
gives 2.62 for 2.62.4.
pkg-config is the de-facto standard for C dependency resolution, virtually all software uses it. It has considered your use-cases, and then some. Targetting earlier libraries is easy, just update the pkg-config path. In fact, NOT using pkg-config is going to be much worse because people will be expecting it to be there and if their system doesn't exactly match your expectations (for include directory, linker flags, etc) then your roll-your-own approach is going to break. For example, with the master branch right now, even if all of the supported versions of everything are installed, gobbi will fail to compile if gio et al are installed to /usr/local instead of /usr.
your roll-your-own approach is going to break
I am using pkg-config courtesy of the cgo comments in the package.go
files. So I'm not sure what roll-your-own approach you're referring to.
I have a feeling that I missing something in what you're saying, but I don't know what.
Does go build
tool provide a way to list all the available built tags? I can't seem to find any
I meant the current approach to building gobbi, where you manually specify a bunch of versions. It's a lot of work on the end user which can be automated.
Should be able to detect the installed package versions with e.g.
pkg-config --modversion gtk+3.0