[RFC] Split tests and examples in KDE4

[Friedrich W. H. Kossebau]

Am Sonntag, 9. Juli 2006 14:16, schrieb Brad Hards:
> G'day,
>
> Currently we have a mixture of automatic tests (using QTestLib), and
> non-automated tests/examples in kdelibs. Mostly, they are in /tests
> subdirectories.
>
> Those are mostly [1] built when you use enable the KDE4_BUILD_TEST option
> to cmake.
>
> I'd like to propose that we split that code into /tests and /examples, with
> separate options to enable each:
>
> $ svn diff cmake/modules/FindKDE4Internal.cmake
> Index: cmake/modules/FindKDE4Internal.cmake
> ===================================================================
> --- cmake/modules/FindKDE4Internal.cmake        (revision 560068)
> +++ cmake/modules/FindKDE4Internal.cmake        (working copy)
> @@ -89,8 +89,9 @@
>  #
>  # The following user adjustable options are provided:
>  #
> -# KDE4_ENABLE_FINAL - enable KDE-style enable-final all-in-one-compilation
> -# KDE4_BUILD_TESTS  - enable this to build the testcases
> +# KDE4_ENABLE_FINAL    - enable KDE-style enable-final
> all-in-one-compilation +# KDE4_BUILD_TESTS     - enable this to build the
> testcases
> +# KDE4_BUILD_EXAMPLES  - enable this to build examples
>  #
>  # It also adds the following macros (from KDE4Macros.cmake)
>  # KDE4_ADD_UI_FILES (SRCS_VAR file1.ui ... fileN.ui)
> @@ -235,6 +236,7 @@
>
>  option(KDE4_ENABLE_FINAL "Enable final all-in-one compilation")
>  option(KDE4_BUILD_TESTS  "Build the tests")
> +option(KDE4_BUILD_EXAMPLES  "Build example applications")
>  option(KDE4_IGNORE_DONTPORT "ignore the \"don't port\" message from
> kdelibs (not snapshot)" OFF)
>
>  #now try to find some kde stuff
>
>
>
> The examples would then be linked into the apidox.
>
> Ideally we'd avoid test applications that aren't automated (i.e. it is
> either an automated test that passes/fails when you "make test", or it is
> an example for users of the class), but I can accept that there might be
> some cases that are very hard to script with QTestLib or Squish or
> KDExecutor (e.g. the visual result is qualitative).
>
> Does this look reasonable?

Yes. I see even more categories:
1. tests
   1.1 automated tests
       1.1.1 short running (< 1 s)
       1.1.2 long running
   1.2 manual tests
2. test utilities (for testing plugins for the module)
3. usage examples

IMHO for those of us who do test-driven programming if would be great if 
building would avoid everything except 1.1.1 if not explictly stated 
otherwise.
For nightly builds then all of 1.1 could be done.
1.2, 2, and 3 would need explicit make calls.
Packagers would like to build only 2.

I think it would be great if (some of) the different options are all contained 
in the build makefiles (using targets), and not need their recreation 
everytime IIUC.

Regards
Friedrich