When building from git it will add targets to generate the swig files.
When building from tarball it will just point at the generated source
files from the tarball.
- 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.
Where possible in the Python SWIG code use the builtin SWIG conversion
code over custom code. This ensures appropriate overflow/type checking.
With this I have enabled GncNumeric from longs and tested for correct
overflow handling.
Note: This could be extended to GUILE but I am not familiar enought to
safely enable this.
At current the Python GncNumeric has issues with type conversion eg.
* GncNumeric(1.3) = 1.00
* GncNumeric("1.3") is OK but any future methods error
This behaviour was relied on for the Account tests to pass as it used
GncNumeric(0.5) == GncNumeric(1.0) but this is not what many users would
expect.
This fix alows GncNumeric to be constructed from a (int, int)
numerator/denominator pair or int/float/str where double_to_gnc_numeric
and string_to_gnc_numeric from C is used.
This will avoid a ninja-build from picking up a config.h generated by the autotools build
(in the root build directory). Picking up the wrong config.h may lead to all kinds of
subtle issues if the autotools run was done with different options than the cmake run.
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.
John Ralls
Geert Janssens
Rob Gowin
Guy Taylor