GNOME Bugzilla – Bug 788561
Document how to integrate GTest into your project
Last modified: 2017-10-11 11:19:53 UTC
See also: https://stackoverflow.com/questions/19958861/how-to-properly-set-up-glib-testing-framework-with-autotools
Created attachment 360968 [details] [review] Document how to integrate GTest into your project We are missing the documentation on how to use GTest inside a project. While we mention in passing gtester and gtester-report, the reality is that we don't tell anybody how to use them inside their own build system. Additionally, gtester and gtester-report are deprecated and kind of abandoned, in favour of tools native to common build systems, such as the TAP harness in Autotools, and the test harness in Meson. See also: https://stackoverflow.com/questions/19958861/how-to-properly-set-up-glib-testing-framework-with-autotools
Review of attachment 360968 [details] [review]: ::: glib/gtestutils.c @@ +178,3 @@ + * + * If your test loads files using g_test_build_filename(), you will also need + * to define the environment necessary for GTest to find those files, e.g.: I think it’s probably simpler to combine the two examples and unconditionally define G_TEST_{SRCDIR,BUILDDIR}, since they’re needed fairly commonly, and if they’re not initially defined by the build system, people might forget about them and come up with some ad-hoc hack instead. @@ +197,3 @@ + * - [glib-tap.mk](https://git.gnome.org/browse/glib/tree/glib-tap.mk) + * - [tap-test](https://git.gnome.org/browse/glib/tree/tap-test) + * - [tap-driver.sh](https://git.gnome.org/browse/glib/tree/tap-driver.sh) tap-driver.sh and tap-test need to be listed in EXTRA_DIST somewhere. (glib-tap.mk does not.)
Created attachment 360972 [details] [review] Document how to integrate GTest into your project We are missing the documentation on how to use GTest inside a project. While we mention in passing gtester and gtester-report, the reality is that we don't tell anybody how to use them inside their own build system. Additionally, gtester and gtester-report are deprecated and kind of abandoned, in favour of tools native to common build systems, such as the TAP harness in Autotools, and the test harness in Meson. See also: https://stackoverflow.com/questions/19958861/how-to-properly-set-up-glib-testing-framework-with-autotools
Review of attachment 360972 [details] [review]: Looks good to push with this change. Thanks! ::: glib/gtestutils.c @@ +216,3 @@ + * Make sure you add `tap-driver.sh` and `tap-test` to the `EXTRA_DIST` + * clause in your project, so they will be part of the distributable + * archive. Probably better to put this in the example code above (as `EXTRA_DIST += \ tap-driver.sh \ tap-test`) or people will copy-paste the code above and miss this paragraph.
(In reply to Philip Withnall from comment #4) > Review of attachment 360972 [details] [review] [review]: > > Looks good to push with this change. Thanks! > > ::: glib/gtestutils.c > @@ +216,3 @@ > + * Make sure you add `tap-driver.sh` and `tap-test` to the `EXTRA_DIST` > + * clause in your project, so they will be part of the distributable > + * archive. > > Probably better to put this in the example code above (as `EXTRA_DIST += \ > tap-driver.sh \ tap-test`) or people will copy-paste the code above and miss > this paragraph. Unless we use: ``` EXTRA_DIST = $(top_srcdir)/tap-driver.sh $(top_srcdir)/tap-test ``` we can't really do this, because the files reside in the top-level. I'm not entirely sure how this will work with recursive Make, and I'm not going to suggest a non-recursive set up.
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > (In reply to Philip Withnall from comment #4) > > Review of attachment 360972 [details] [review] [review] [review]: > > > > Looks good to push with this change. Thanks! > > > > ::: glib/gtestutils.c > > @@ +216,3 @@ > > + * Make sure you add `tap-driver.sh` and `tap-test` to the `EXTRA_DIST` > > + * clause in your project, so they will be part of the distributable > > + * archive. > > > > Probably better to put this in the example code above (as `EXTRA_DIST += \ > > tap-driver.sh \ tap-test`) or people will copy-paste the code above and miss > > this paragraph. > > Unless we use: > > ``` > EXTRA_DIST = $(top_srcdir)/tap-driver.sh $(top_srcdir)/tap-test > ``` > > we can't really do this, because the files reside in the top-level. I'm not > entirely sure how this will work with recursive Make, and I'm not going to > suggest a non-recursive set up. I was assuming non-recursive automake, since that’s the recommended way of autotooling yourself. Why would you not suggest it? You could put the EXTRA_DIST example in a separate code block and say to put it in the top-level Makefile.am.
Created attachment 361302 [details] [review] Document how to integrate GTest into your project We are missing the documentation on how to use GTest inside a project. While we mention in passing gtester and gtester-report, the reality is that we don't tell anybody how to use them inside their own build system. Additionally, gtester and gtester-report are deprecated and kind of abandoned, in favour of tools native to common build systems, such as the TAP harness in Autotools, and the test harness in Meson. See also: https://stackoverflow.com/questions/19958861/how-to-properly-set-up-glib-testing-framework-with-autotools
Here’s an updated patch with my suggestion incorporated. What do you think?
Review of attachment 361302 [details] [review]: Looks good; thanks for the update.
Attachment 361302 [details] pushed as 17e29be - Document how to integrate GTest into your project