GTK versions

As the tarball has been prepared, a call to './configure' will by default configure the library for GTK+3. However, if './configure-gtk2' is called, then the library will be prepared for compilation against GTK+2.

To configure and compile for GTK+2, GTK+ version 2.10.0 or greater is required. To configure and compile for GTK+3, GTK+ version 2.90.0 or greater is required. Version 2.99.0 or greater is required for the Cgu::Application class to be compiled in.

The compilation default can be changed to GTK+2 by calling './bootstrap-gtk2.sh'. If so changed, to compile the library then against GTK+3 it is necessary to call './configure-gtk3'. To change the default back to GTK+3 again, call './bootstrap-gtk3.sh'.

However the default is set, the library can always be explicitly prepared for compilation against GTK+2 by calling './configure-gtk2' and for compilation against GTK+3 by calling '/configure-gtk3'. It will therefore not generally be necessary to call either bootstrap-gtk2.sh or bootstrap-gtk3.sh.

The library as compiled for GTK+2 and for GTK+3 can be parallel installed. To configure a user program to link against the library as installed for GTK+2, use c++-gtk-utils-2-2.0.pc, and to configure to link against the library as installed for GTK+3, use c++-gtk-utils-3-2.0.pc. This is different from the 1.2 series of c++-gtk-utils, which provided c++-gtk-utils-1.2.pc when compiled against GTK+2, and c++-gtk-utils-1.3.pc when compiled against GTK+3, which in retrospect was somewhat odd numbering. This 2.0 series of the library can also be parallel installed with the 1.2 series.

'make install' will also put the headers in different places: for the library as installed for GTK+2 these are in $prefix/include/c++-gtk-utils-2-2.0/c++-gtk-utils, and for GTK+3 in $prefix/include/c++-gtk-utils-3-2.0/c++-gtk-utils. The reason for this is that although the library headers themselves are at present identical in either case, the installed file cgu_config.h, which is produced when running './configure' and its siblings, might be different if different compilation options are chosen. This would allow, for example, the GTK+2 binary to be compiled to use glib memory slices, and the GTK+3 binary to be compiled to use the global new/delete operators. This separation also gives more scope for differentiation in the future, depending on how GTK+3 develops.

Although as mentioned above there are separate dynamic and static library installations for GTK+2 and GTK+3 at the binary and header level, they provide the same documentation (which is normally located in $prefix/share/doc/c++-gtk-utils/2.0). This means that if you run 'make uninstall' against, say, the tarball as configured for GTK+2, but want to retain the documentation for future use for GTK+3 applications, it will be necessary to run 'make install' again against the tarball configured for GTK+3. (So far as the distributions' packaging management utilities are concerned, it might be better for a single c++-gtk-utils package to have within it the binaries for both GTK+2 and GTK+3 where that distribution provides both GTK+2 and GTK+3, but if separately packaged the packaging utilities will handle the situation as files common to two packages will not be deleted unless both packages are removed.)