By properly marking certain parameters as private or public
we can have cmake work out most of the link_libraries and
include_directoris for other targets dependent on core-utils
- first all rules and variables for libgnc-core-utils
- then the rules to generate additional files (like
gncla-dir.h or gnc-vcs-info.h)
- next rules for the python bindings
- finally rules for the dist targets
Note this commit also eliminates variable
core_utils_ALL_SOURCES, replacing its two
uses directly with its value.
* Eliminate redundant variables (core_utils_ALL_INCLUDES, core_utils_ALL_LIBRARIES)
Their values are used directly in target_include_directories and
target_link_libraries respectively.
They have been eliminated from the python target because target_include_directories
and target_link_libraries will correctly propagate these values.
* Use generator expressions for a few conditional compile defines and options
Note core-utils.i is used by both the guile and the python bindings so
it is moved up to the common bindings directory, while guile
specific changes are in bindings/guile.
This reverts commit 1a9fcfefad because
on MinGW cmake complains about the paths in pkgconfig files. This can
be addressed by using the MSYS2 cmake instead of the MINGW32 one, but
that requires some other changes... and there's also a path separator
bug in that version of FindPkgConfig.cmake.
This simplifies a number of escape sequences.
The generated file to configure the man page was split up a bit further:
- code that extracted the GNC_VCS_REV_Y_M from gnc-vcs-info.h was spun out
into its own function that now sets all parameters in gnc-vcs-info.h
as environment variables.
- this function is now invoked by configure-manpage.cmake to extract
the date to insert into the manpage.
- the manpage in addition now shows the full date rather than only
yyyy-mm. This is how man itself does it as well.
We can't use std::locale::global because all streams imbue it by
default and if it's not 'C' (aka std::locale::classic) then we
must imbue all the streams that we don't want localized, and that's
most of them.
Provides error checking for setting the C++ locale from the environment.
This is necessary both because the environment might have an invalid
locale, which would cause an unhandled exception crash.
On windows std::locale("") can't handle some Microsoft-style locale
strings (e.g. Spanish_Spain) so we use boost::locale's gen("") function
to set the locale--though even that can't handle a Microsoft-style
locale string with an appended charset (e.g. Spanish_Spain.1252) and
that's what glibc's setlocale(LC_ALL, NULL) emits.
Always use absolute paths for configured directories (BINDIR etc.)
Abstract out the guts of gnc_gbr_find_foo_dir for foo in lib, bin, and data.
etc requires special handling because of the way it's treated if prefix
begins with /opt.
Always fall back on the configured directory if binreloc is disabled and
no default is passed in.
The swig 3.0 generated python wrappers trigger a warning converted into an error issued
by gcc 8.0 for using strncpy as follows:
strncpy(buff, "swig_ptr: ", 10);
The reason is this call will truncate the trailing null byte from the string.
This appears to have been fixed in swig master already but that's not released yet
so let disable the warning when compiling the swig wrappers until it is.
Replacing libgncmod-python, libgncmod-core-utils-python, and
libgncmod-app-utils-python with _sw_core_utils and _sw_app_utils.
The latter two are the modules that init.py wants to load and with
Python3 Swig appears to no longer make them available via libgncmod.
Note that there may still be some problems with actually using the
console, but it at least loads at startup without complaint.
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.
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.
Geert Janssens
John Ralls
Rob Gowin