992e064952
2000-01-16 Martin Baulig <martin@home-of-linux.org> We now use `@LIBGTOP_PACKAGE@' as the translation domain so installed `libgtop-1.1.mo' files won't conflict with the ones from LibGTop 1.0 and you can keep both versions installed. * po/Makefile.in.in.in: New file. This is a modified version of the usual `Makefile.in.in' which is created by gettextize; we copy this over `Makefile.in.in' in autogen.sh after gettextize'ing. * autogen.sh: Copy `po/Makefile.in.in.in' over `po/Makefile.in.in' after running `macros/autogen.sh'. * configure.in (LIBGTOP_PACKAGE): AC_SUBST and AC_DEFINE this. * include/glibtop/global.h (_): Use `LIBGTOP_PACKAGE' as our translation domain. 2000-01-16 Martin Baulig <martin@home-of-linux.org> * LIBGTOP-VERSION (LIBGTOP_VERSION_SUFFIX): Added this so you can have your tarballs called `libgtop-1.x.y-snap.tar.gz' or whatever. This only affects the `VERSION' variable and thus how the resulting tarball will be called, but not `LIBGTOP_VERSION_CODE' etc. * Makefile.am: Make `aclocal.m4' also depend on `LIBGTOP-VERSION' when in maintainer-mode.
This is the *development* branch of LibGTop. It is indended for people who want to help with the development of LibGTop and not for end-users. Please use the LIBGTOP_STABLE_1_0 branch (which is LibGTop 1.0.x) unless you're really a developer. If you're using LibGTop from CVS simply do a cvs update -r LIBGTOP_STABLE_1_0 to get the latest version from the stable branch. However, I'll periodically make snapshot releases from the development branch for Solaris users of LibGTop. They can be found at ftp://ftp.home-of-linux.org/pub/libgtop/1.1/ in near future. Using released tarballs from the development branch is a lot better than compiling directly from CVS since things in CVS may not always work as expected. Note that releases from the developer branch are neither binary nor fully source compatible; you'll normally have to recompile everything that use them. October 1999 Martin Baulig