Use pkg-config to automatically generate build tags

[ddevault]

Should be able to detect the installed package versions with e.g. pkg-config --modversion gtk+3.0

[pekim]

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.

[pekim]

And of course one may wish to build targetting earlier versions of libraries than those installed locally.

[ddevault]

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.

[pekim]

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.

[rythmkraze]

Does go build tool provide a way to list all the available built tags? I can't seem to find any

[ddevault]

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.