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.
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.
Sets paths for finding componenents depending on the state of ENABLE_BINRELOC,
GNC_UNINSTALLED, GNC_BUILDDIR and whether any install paths have been set
outside of CMAKE_INSTALL_PREFIX.
GNUInstallDirs changes the name of CMAKE_INSTALL_LIBDIR depending on the
operating system and distro. When CMAKE_INSTALL_PREFIX is /usr,
/usr/local, or any subdirectory of /opt it also changes
CMAKE_INSTALL_FULL_SYSCONFDIR to /etc. An earlier commit by Aaron Laws
mirrors the name of CMAKE_INSTALL_LIBDIR to the build library directory.
It's possible for builders to set any of the install directories
anywhere they please.
Setting any directory outside of CMAKE_INSTALL_PREFIX breaks Binreloc so
the toplevel CMakeLists.txt now detects that and disables Binreloc.
If Binreloc is enabled then all path queries use it to find paths. This
works in the build directory because the gnucash executable and all of
the test programs are in build_directory/bin and LIBDIR, DATADIR, and
SYSCONFDIR can be found in the same root path.
If Binreloc is disabled then in order to build or run programs from the
build directory one must set GNC_UNINSTALLED and set GNC_BUILDDIR to the
absolute path of the build directory. When those are set GNC_BUILDDIR
replaces CMAKE_INSTALL_PREFIX in all paths that are subdirectories of
CMAKE_INSTALL_PREFIX; paths that are not in CMAKE_INSTALL_PREFIX are
appended whole to GNC_BUILDDIR. This process is constent between CMake
and gnc_path_get_foo. GnuCash is unlikely to run from a DESTDIR without
Binreloc.
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.
The utf8 conversion is only used in the Windows specific section so there's no
need to define an overloaded function on std::string in this case.
Also CMakeLists.txt doesn't require the MingW specific library name setting
for boost::filesystem. Just removing the hardcoded one allows the build to
pick the right name up from the Boost_LIBRARIES variable.
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.
