1. If GTEST_ROOT and/or GMOCK_ROOT are defined, sources are expected
somewhere inside these directories. Otherwise a CMake error is
generated. Different source directory layouts are considered.
2. If GTEST_ROOT and GMOCK_ROOT are both not defined, sources are
searched in /usr/src. Different source directory layouts are considered.
3. If sources are not found in one of the first two cases, preinstalled
libraries are searched.
Additionally using HINTS in function find_path() has been replaced by
PATHS and PATH_SUFFIXES. According to CMake documentation in case of
hard-coded guesses PATHS should be used. Remark: This reverts commit
5f53e29, but instead NO_CMAKE_SYSTEM_PATH is used now to prevent CMake
from searching in system paths.
Hint: There was a special handling implemented regarding search for
gmock-all.cc. This file was additionally searched in /usr/src/gmock
directly instead of /usr/src/gmock/src (see commit 1241b71). This
special handling has been kept in case of searching sources in
/usr/src/gmock, but not in case of searching sources in GMOCK_ROOT or
GTEST_ROOT.
if GTEST/GMOCK sources are already found, only check if gtest/gtest.h
and gmock/gmock.h exist at GTEST_SRC_DIR/include and
GMOCK_SRC_DIR/include and set GTEST_INCLUDE_DIR and GMOCK_INCLUDE_DIR
accordingly.
This simplifies usage of GoogleTest, since independent handling of
GTEST_LIB and GTEST_INCLUDE_DIR is not necessary anymore.
Additionally CMake creates a dependency now between target gtest and all
test applications using it. This improves build process when building
GoogleTest from source code. When any test application is built,
GoogleTest library is automatically rebuilt if necessary now for
instance.
Currently when compiling GoogleTest from source code, source file
gtest_main.cc from GoogleTest repository is not compiled into any
library as in GoogleTest repository, where it is compiled into
libgtest_main.a. Instead gtest_main.cc is added to source file list
GTEST_SRC, which is then added to the list of source files of every
single GoogleTest based test application.
To simplify this gtest_main.cc is added to the source file list of
target gtest now. Additionally GTEST_SRC is merged into
lib_gtest_SOURCES, since both variables defined source files for
GoogleTest libraries.
Now target gtest generates library libgtest.a, which already contains
the main function from source file gtest_main.cc. This is different to
GoogleTest build system, where both are separated into two independent
libraries libgtest.a and libgtest_main.a.
The function accepts the name of a deprecated module and optionally a
replacement module.
With that info it will generate a stub guile module that
- will be installed in the gnucash guile load path
- emits a deprecation warning when the old module is used
- if a replacement module is given, will automatically load that module instead
This allows us to gently deprecate complete guile modules without
the burden of manually maintaining their module files.
Any scm file that will be built may need access to other scheme files that may have
been linked into that directory. As it was only scm files that would be linked
themselves would also be built with the search path set, causing other linked files
not to be found for an scm file that doesn't add a link for itself.
There are more, but these are most common ones.
There are also a number of urls that don't behave well when https, so those are skipped
At some point I have also started marking non-working URLs as [DEAD LINK], though
that's not a full coverage.
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
There were several issues:
- we store the compiled test*.go files in a tests subdirectory, but this is not
on the GUILE_LOAD_COMPILED_PATH. Added this directory to the path.
- guile was looking for 'script.scm.go' while we create 'script.go'. This is due
to how we invoke the scripts: guile -l path-to-script.scm -c (something)
we can replace this with -l path-to-script (without extension) as -l won't add
the extension. So I've rewrittin the test command to invoke (load-from-path).
- the test modules foo.scm, bar.scm and baz.scm should go in tests/gnucash
as they are defined as modules (gnucash foo), (gnucash bar) and (gnucash baz)
respectively.
- find html.scm/go on the load path instead of using a relative path.
This switches swig to use python 3 specific features when generating the
bindings, switches the build over to python 3 and makes the neccesary
python 2 to 3 conversions in the bindings and tests.
- Don't attempt to create a subdirectory of a non-existing home directory (use tmpdir as base directory in that case)
- Make sure all tests run in an environment with GNC_BUILDDIR and GNC_UNINSTALLED set. Otherwise
the one-shot old .gnucash to new GNC_DATA_HOME migration may already have run at build time,
preventing us from informing the user a run time.
- Re-enable the userdata-dir with invalid home test (linux only).
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.
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.
