- only abort configuration if gettext is older than 0.18.1 (required for string extraction from scheme files)
- otherwise always continue but disable a few other build steps depending on the gettext version
- use feature variables to more clearly convey what is enabled or disabled
This starts by setting the gnucash version number in the 'project' call.
This will result in a number of variables set by cmake. The remainder
of this commit is to reuse the auto-generated
PROJECT_NAME, PROJECT_VERSION, PROJECT_VERSION_MAJOR
PROJECT_VERSION_MINOR, PROJECT_VERSION_PATCH and PROJECT_VERSION_TWEAK
instead of all the various instances of PACKAGE, GNUCASH_MAJOR_VERSION
and so on.
One parameter is worth mentioning - GETTEXT_PACKAGE
GnuCash is not using this directly (any more) but it has to be set before
including gi18n-lib.h.
This version is available for all supported platforms and distros
(CentOS can have a version via EPEL, which is required anyway)
Advantages:
- one cmake version for all platforms
- we can drop all conditions based on cmake version
As part of this also:
- Drop POTFILIES.ignore. Relevant lines have been moved to POTFILES.skip
- Remove skip lines for scm file links. With intltool out of the way these are never picked up any more.
By default we require gettext 0.19.6 as this is needed to generate a translated version of gnucash.desktop and gnucash.appdata.xml.
However this version is not available on some platforms (most notably our own ubuntu 14.04LTS travis instance).
By setting ALLOW_OLD_GETTEXT=ON, the build configuration falls back to generating untranslated versions of said files instead.
At present these are
- log.conf
- config-user.scm (previously config.user-2.0)
Implement one-time migration of these files to the proper directory if they previously exist
Look for a log.conf file in gnc_userconfig_dir instead of gnc_userdata_dir
Note this commit also uses boost::locale::translate for the first time.
We may need to fine-tune our use, but in the current state strings marked
for translation using that function are already picked up for gnucash.pot.
The swig wrappers don't really depend on git (but rather on swig) and there can be
situations the builder wants to generate the wrappers also from a tar ball.
- add simple target called 'pot' so translators can run 'make pot'
- make gnucash.pot depend on all files with translatable strings. So whenever
one of these files is changed the potfile will automatically be regenerated
(if the current target depends on it, like 'pot' or 'dist')
Note the default target (make without anything) does not depend on gnucash.pot
so the potfile will not automatically be (re)generated when building that target.
- the two dist_add_... macros now both take a list of file names
as argument so more files can be added at once to the dist tarball.
- dist_add_generated now creates the right target by itself. There's
no need to pass one any more
- make the swig generated *.py module files explicit output files
- change a couple of custom_targets into custom_commands. The only
reason they were defined as targets was to ensure they got built
before the dist tarball. This is now properly handled by the
dist_add_... macros.
- correctly handle dependency on swig-runtime.h (using OBJECT_DEPENDS
was not the way to do it according to that property's help page)
cmake with unix makefiles fails to resolve dist dependencies
added from COPY_FROM_BUILD if these dependencies aren't built yet.
This commit replaces the COPY_FROM_BUILD based logic with two new functions
'dist_add_configured' and 'dist_add_generated' to indicate which files should
be included in the dist tarball. The latter also adds a target level dependency
to the dist tarball custom command. Hence the former should
be used for files that get generated during a cmake run while the latter
should be used for files generated as the result of a 'make/ninja-build' run
(like files for which an add_custom_command rule exists).
Note: this commit also temporarily disables the dist target when building
from a tarball (and hence it won't be tested in distcheck either). This
will be handled in a future commit.
This includes removal of the now unused make-gnucash-potfiles.in,
checking for CMakeLists.txt rather than Makefile.am in gnc-vcs-info,
upating the HACKING file,
and generally updating references to autotools.
I have kept "Makefile.*" exclude patterns in our CMakeLists.txt files
because they may still be lingering in the source directory from
previous autogen.sh runs. At some point these should probably be
removed as well still, together with the gitignore references to them.
This effectively replaces the use of GNUCASH_BUILD_DATE with GNUCASH_SCM_REV_DATE.
The latter is extracted from the current commit if building from some kind of vcs
(currently only works correctly for svn and git). The info extracted while building
from vcs is then also added to the dist tarball so it's available when building
from tarball as well (via the file libgnucash/core-utils/gnc-vcs-info.h).
The same date is also used to set the date in gnucash' man page document.
A practical detail: I have changed the substitution variables in the man page template
from @- -@ to ${} so we could leverage CONFIGURE_FILE in cmake. The necessary
related adjustments have also been made to Makefile.am's substitution rules.
intltool-update should be run from the build directory, not the source directory.
If run from the source directory it will omit glade messages that have a context attribute
so all msgids with a msgctxt comment would be missing.
On Windows CMake converts "\n" to CRLF, which causes xgettext to
mangle paths with [type: gettext/gsettings] in front of them and
also dirties the source directory with uncommittable changes.
The autotools build doesn't regenerate POTFILES.in and we've historically
maintained it by hand.
Apparently that platform trips over a missing newline at the end of the generated POTFILES.in.in file.
Adding one allows cmake to complete configuration and appears to be fine on Fedora as well
(although it worked fine without the newline too).
Thanks go to Michael Jung <gnucash-devel@mailinglists.mjung.org> for reporting this and proposing the fix.
It is split into
- /libgnucash (for the non-gui bits)
- /gnucash (for the gui)
- /common (misc source files used by both)
- /bindings (currently only holds python bindings)
This is the first step in restructuring the code. It will need much
more fine tuning later on.
These are currently unmaintained, cutecash us based on the obsolete qt4
and gtkmm is only used by cutecash. Whenever someone wishes to revive
this experiment it can be recovered from git history and be brought
into a separate repository.
They are both about handling core gnucash objects. Qof was once split out
in an attempt to make it a separate library. This hasn't worked out so there's
no good reason any more to keep this artificial separation.
A few considerations:
- The qof tests are merged into the engine test directory but they are kept as
a separate test entity for now. Several assumptions made in the qof tests
are no longer valid in the context of the engine. (For example if the
pricedb test is added in the same test executable as the qofbook test,
the book creation test fails because it now has 2 collections (pricedb and
book) instead of only one. There are plenty of others like this so merging
the tests needs more careful review and is perhaps best done while converting
to c++/Google test.
- I had to use unique names for the MockBackend classes because apparently the tests were
using a MockClass from another file in the cmake builds, causing several
tests to fail.
