http://bugs.ledger-cli.org/show_bug.cgi?id=985
Fix compilation issue on Cygwin by adding the '-U__STRICT_ANSI__' flag
to GCC. This avoids GCC disabling some stdlib functions like 'setenv'
and 'popen'.
to remove the warning below when running cmake.
In the long run changing the CMake rules to set MACOSX_RPATH
might be the better option.
CMake Warning (dev):
Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake
--help-policy CMP0042" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
MACOSX_RPATH is not specified for the following targets:
libledger
This warning is for project developers. Use -Wno-dev to suppress it.
If set, the COLUMNS environment variable will take precedence over terminal
width. However, please note that COLUMNS is usually *not* exported by shells to
child processes, so in most cases COLUMNS will be undefined for ledger---hence
the motivation for this change.
Terminal width is queried using ioctl() on stdin. For the sake of portability
the querying is done only on platform where ioctl() is detected as supported at
compile-time.
sha1.cc is not redistributable by Debian because the license doesn't
permit redistribution of modified versions.
This isn't ideal since the ::details namespace is subject to change,
but it avoids adding a dependency to ledger.
CMake will build the pdf version of the manual if texi2pdf is installed.
It will be installed to DOCDIR/ledger{,3}.pdf, for example
/usr/local/share/ledger/ledger3.pdf.
Also, the man page will be installed to MANDIR/man1/ledger.1
The option BUILD_DOCS is now on by default.
A new option BUILD_WEB_DOCS is used to toggle the generation
of the html version of the manual and the man page (off by default).
All this is added to the 'doc' make target.
Indeed, at the moment, it doesn't work against Python 3.x at all, so
ideally, we'd like to tell CMake that no Python versions except 2.7 and
2.6 are acceptable. However, at least as of CMake 2.8.8, there appears to
be no way to instruct CMake to never consider other versions of Python.
In other words, Python_ADDITIONAL_VERSIONS is prepended to the list of
possible Python versions considered, rather than replacing it wholly.
Theoretically, we could try to diddle withe the internal CMake variables
_PYTHON_FIND_OTHER_VERSIONS or _Python_VERSIONS somehow, but that seems
kludgey and dangerous. This patch is probably "enough for now" to at
least make sure that if the user has both Python 2.x and Python 3.x
installed, some version of 2.x that is known to work will be preferred.
