GNOME Bugzilla – Bug 338342
pkg-config check in gtk-doc.m4 isn't versionned
Last modified: 2014-02-17 21:12:15 UTC
Hi there, while reviewing gtk-doc 1.6, I've seen you added: # Make sure we have pkg-config >= 0.19, so installing in $(datadir) is OK. PKG_PROG_PKG_CONFIG([0.19]) in configure.in. The intent seems to fail building gtk-doc would pkg-config >= 0.19 not be available. First, it doesn't fail if pkg-config isn't there; second, I think that this check belongs to the build time of other packages. Sadly, adding the test to gtk-doc.m4 seems pointless as packages using this macro are unlikely to check again with PKG_CHECK_MODULES afterwards. I don't see a real solution besides documenting this and rely on package maintainers to use some package dependencies to pull the correct pkg-config when gtk-doc is installed. Cheers,
Yes, it looks like we need something like: if test -z "$PKG_CONFIG"; then AC_MSG_ERROR([pkg-config >= 0.19 is required for gtk-doc]) fi I don't think we need to worry about other packages though. We just need to ensure that if gtk-doc >= 1.6 is installed, then pkg-config >=0.19 is used. (Or have I missed something?)
The test is useless: you don't need pkg-config >= 0.19 when you *build* gtk-doc, but when you PKG_CHECK_MODULES([gtk-doc]) in another module (indeed when gtk-doc is installed). Since there's no easy way for you to run some code prior to the PKG_CHECK_MODULES() call of another module's configure to ensure that pkg-config is >= 0.19, you should simply rely on package maintainers to do the right thing (e.g. let gtk-doc depend on pkg-config >= 0.19). So IMO, remove the current test and document the need for pkg-config >= 0.19 when one wants to use PKG_CHECK_MODULES([gtk-doc]).
The check is basically saying that gtk-doc 1.6 depends on pkg-config >= 0.19, and it should refuse to install if the right pkg-config isn't available. I still can't see a problem with that. It is easier than telling app maintainers they all need to check for pkg-config >= 0.19.
It's not saying that gtk-doc 1.6 depends on pkg-config, it's saying it *build-depends* on pkg-config. Debian packages are *built* (./configured) on a buildd machine and result in *.deb actually shipping the binaries. Your test would worse the package maintainer (me) to add a build-dependency on pkg-config -- even if it's not needed to build the gtk-doc package! -- but wouldn't prevent people from installing the resulting gtk-doc package without pkg-config. ./configure is what happens when the maintainer prepares the package, and is not the place to put checks for things which are needed at runtime. The place where one can say "gtk-doc's pkg-config file can only be used if you have pkg-config >= 0.19" is the Debian package holding gtk-doc's pkg-config file. The expression of this dependency is the burden of the package maintainer (me), which can Suggest, Recommend, or Depend on the pkg-config package in the appropriate version. I hope this clears up why a pkg-config check is useless to run at the time gtk-doc is built.
Putting checks in configure.in for runtime dependencies is normal, and has little downside for something like pkg-config which is unlikely to create a build loop. While it doesn't *help* getting package dependencies right, it does help people installing from source, who have a hard enough time as it is. gtk-doc similarly checks for xslt, etc, in its configure.in, which it needs at run time.
Please please please, I'm fine with an informative warning to the user who is building gtk-doc, but don't let ./configure fail just for the sake of users building from sources (which should use supported build tools or daily packages anyway, building from source manually should be eserved to developers). Besides, using pkg-config to check for gtk-doc is quite uncommon, so requiring it for all installations would be really a shame.
Wouldn't it be easier to just add the build requires and move on?
I think using pkg-config to check for gtk-doc is normal. We tell people to use the macro: GTK_DOC_CHECK(1.0) which uses pkg-config to do the version check. I still don't understand what major problems this is supposed to cause. Surely packages are built using the latest versions of things like pkg-config anyway? I think people building from source have a higher priority anyway, and I'd like to make sure it fails with a good error message when building gtk-doc rather than fail with a vague message later when building random packages. (Packagers can patch the check out if they really need to.)
Yes, we can patch the checkout and that's painful, we'd have to do this for no actual gain, it means I need a new patch for each release touching configure.ac, and another patch after an autoconf re-run. Please, just make it a warning "XXXXX WARNING: you seem to miss pkg-config >=0.19": it serves the same purpose without adding useless contentions. Or make it a flag --dont-check-runtime-deps if you really want the default behavior to FAIL.
Why the heck would you patch the package rather than just adding the (maybe extraneous, but harmless) build-requires? Seems like you are just making more work for yourself. Anyways, Damon's call, not mine. (Non-fatal warnings from configure generally get ignored by users, because they simply won't be seen no matter how many XXXX or **** ou put around them in the rest of the output from configure.)
It's acceptable to add tiny build-dependencies such as pkg-config, it's jsut a bad trend that I can't accept, the typical example being python imports which inflict stupid buildd pressure and don't represent anything. I already added the build-depend (prior to opening this bug), and I have also been the victim of needing to patch configure: http://svn.debian.org/wsvn/pkg-gnome/desktop/unstable/gtk-doc/?rev=5664&sc=1 http://svn.debian.org/wsvn/pkg-gnome/packages/experimental/pessulus/?rev=5667&sc=1 (It's not like I'm complaining only for the sake of it, I really think it's a wrong trend.) (I'm going offline for Eastern, happy Eastern!)
Does pkgconfig install a .pc file itself ? In that case, we could simply add a requirement for pkgconfig >= 0.19 to the gtk-doc.pc file...
Matthias, it would have been clever and elegant, but no: pkg-config does not install a pkg-config file.
So it seems like we choose one of: a) make gtk-doc depend on pkg-config 0.19. b) make sure that all packages that use gtk-doc depend on pkg-config 0.19. (a) is trivial to do. (b) is just not realistic. So I'm afraid I think I'll add the check in a few days.
If you go and add fatal checks at build time, please let packagers turn them off via e.g. a config flag.
Damon, what was the conclusion here and what exact change should be made in which file?
Loïc, > The place where one can say "gtk-doc's pkg-config file can only be used if you > have pkg-config >= 0.19" is the Debian package holding gtk-doc's pkg-config > file. this is not (only) about the .pc file. gtkdoc-fixxref and gtkdoc-rebase use pkg-config run time to link cross references. (Granted, they do not work on Debian at all thanks to the wonders of compressed documentation, but that's another matter.) So the point is really that packages check for dependencies build time and the results of these checks have run-time implications. The expected effect of --disable-pkg-config would be that the package disables all its uses of pkg-config, but this is not the desired effect. Of course, if the option was designed as a specific Debian packaging workaround (--disable-pkg-config-check-I-swear-it-will-be-present) it could work differently, also the pkg-config absence is not so critical so the code could be just left there, just please notice what is the norm. If you really, really want to disable a configure check for something used by the package, because you happen to know it will be available run-time but do not want to make it available build-time, patching configure is quite reasonable.
Now that I re-read this bug report of mine after a while, I think I was angry after I saw many packages add runtime checks to their configure.ac, but that the case of gtk-doc was really minor (lowering severity to minor). I think there was a decent solution to solve the same problem back then: simply move PKG_PROG_PKG_CONFIG([0.19]) from configure.ac to gtk-doc.m4. Nowadays, there's a real need to build-depend on pkg-config: glib_prefix="`$PKG_CONFIG --variable=prefix glib-2.0`" So the only remaining issue is that gtk-doc.m4 doesn't enforce the pkg-config version, but that's about it (updated summary); it's an issue I can live with as we already bumped the dependencies and build-dependencies properly in Debian, and we generally bump the versions both in build-deps and deps at the same time. Please feel free to close the remaining bug if you don't intend to version the check in gtk-doc.m4. (In reply to comment #17) > this is not (only) about the .pc file. gtkdoc-fixxref and gtkdoc-rebase use > pkg-config run time to link cross references. That's an important point, thanks for mentioning it (gtkdoc-fixxref.in and gtkdoc-rebase.in don't use the result of PKG_PROG_PKG_CONFIG though). > (Granted, they do not work on > Debian at all thanks to the wonders of compressed documentation, but that's > another matter.) It's the first time I hear about this problem, and I would be happy to discuss possible solutions (be it to recommend not zipping what you think shouldn't be or allowing gtkdoc-* to handle zipped files). > If you really, really want to disable a configure check for something used by > the package, because you happen to know it will be available run-time but do > not want to make it available build-time, patching configure is quite > reasonable. Sorry, but that seems wrong, and it's painful: it requires updating the configure patch for each new release or -- awfulness -- build-dep on autoconf. Runtime checks should simply be done at runtime. :-)
(In reply to comment #18) > Nowadays, there's a real need to build-depend on pkg-config: > glib_prefix="`$PKG_CONFIG --variable=prefix glib-2.0`" Well, this is only used for tests and executed optionally; and tests create a circular(!) dependency on GLib so depending on your setup and approach you may want to avoid them. Note I'm not arguing with myself here... I'm just explaining that this is a rather marginal reason. > gtkdoc-fixxref.in and > gtkdoc-rebase.in don't use the result of PKG_PROG_PKG_CONFIG though. Maybe they should, maybe they should not. Hardcoding the path means you cannot make it use a different pkg-config just by changing the PATH, you have to rebuild gtk-doc. > It's the first time I hear about this problem, I reported it to Ubuntu last year (wondering why no one had noticed it before) https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/77138 Isn't there some bug sharing? Or maybe it needs someone to explicitly do something to make it happen... > and I would be happy to discuss > possible solutions (be it to recommend not zipping what you think shouldn't be > or allowing gtkdoc-* to handle zipped files). If you ask me, the answer will be simple: not zipping, of course. I questioned the benefits of saving some space by making file names unpredictable and their contents unreadable (try to find something with `grep -r') ten years ago when the size of my disk was 250 MB, not 250 GB. Nowadays... I will refrain. > Sorry, but that seems wrong, and it's painful: it requires updating the > configure patch for each new release or -- awfulness -- build-dep on autoconf. > Runtime checks should simply be done at runtime. :-) And programs should search for and carefully try to dlopen all libraries they use on startup... Somehow I feel this is not going to happen... But back to the point. If you admit gtk-doc can build-depend on pkg-config, I think this issue can be closed.
(In reply to comment #19) > > gtkdoc-fixxref.in and > > gtkdoc-rebase.in don't use the result of PKG_PROG_PKG_CONFIG though. > > Maybe they should, maybe they should not. Hardcoding the path means you cannot > make it use a different pkg-config just by changing the PATH, you have to > rebuild gtk-doc. You clearly should not hardcode the path IMO; otherwise, the local admin can't use standard practice of dropping replacements in /usr/local/bin (or sbin). > > It's the first time I hear about this problem, > I reported it to Ubuntu last year (wondering why no one had noticed it before) > https://bugs.launchpad.net/ubuntu/+source/gtk-doc/+bug/77138 > Isn't there some bug sharing? Or maybe it needs someone to explicitly do > something to make it happen... (/me lols @ bug sharing :-) Distributors rarely read each other's bug trackers, except perhaps when looking for issues they already know exist I guess. We have a big enough pile of bugs on each side... :) But I subscribed to the Ubuntu bug you reported, and would be happy to pursue discussion there too. > > and I would be happy to discuss > > possible solutions (be it to recommend not zipping what you think shouldn't be > > or allowing gtkdoc-* to handle zipped files). > If you ask me, the answer will be simple: not zipping, of course. > > I questioned the benefits of saving some space by making file names > unpredictable and their contents unreadable (try to find something with `grep > -r') ten years ago when the size of my disk was 250 MB, not 250 GB. > Nowadays... I will refrain. grep -r will only give interesting results in very specific document formats, not in video files, not in audio files, probably not in many PS or PDF files, not in DVI files, not in MSWord files; you get the idea. I do think we use compression a lot, not only to save space on our hard disk, but also to have faster load time (CPU being usually idle while disk slows down loading). Plus there are still some space tight use cases such as live CDs (but I grant you that developer documentation usually isn't shipped on live CDs): we do have to zip READMEs, copyright information, changelogs and the like that are shipped on live CDs. Use Tracker, Beagle or whatever to find random stuff: it certainly can introspect zipped data. > > Runtime checks should simply be done at runtime. :-) > And programs should search for and carefully try to dlopen all libraries they > use on startup... Somehow I feel this is not going to happen... Uh it's pretty much happening: the linker checks for the proper SONAME/ABI and will report to you if it doesn't find it. Don't laugh, but there are real examples of programs dlopen()ing libs and checking their version such as Eclipse, VMWare, JMF etc. IMHO, we do lack a machine-parseable format of runtime dependencies, but while this wont be solved overnight, you can still code simple checks before using programs: "Your version of pkg-config is too old". thomasvs, my hero, suggest it's possible to write dependency checks as in moap: https://thomas.apestaart.org/moap/trac/browser/trunk/moap/util/deps.py > But back to the point. If you admit gtk-doc can build-depend on pkg-config, I > think this issue can be closed. I added the build-dep from day 0 when I reported the bug, and it seems useful for the test suite, but I also updated the bug's summary to reflect what IMO could still be enhanced: adding a check for the pkg-config version in gtk-doc.m4.
Closing this bug as wontfix. 1) AC_REQUIRE([PKG_PROG_PKG_CONFIG]) cannot take the version parameter 2) the version cehck is needed when building gtk-doc 3) that 0.19 is there unchanged for year and probably easy to satisfy everywhere.