When the Doxywizzard GUI is used and the doxyfile is loaded, the
workind directory for doxygen is set to the location of the doxyfile.
However the Make and CMake build systems expect doxygen to be ran
from the top level directory.
This commit unifies the build system and the Doxywizzard GUI so that
all of them expect doxygen to be executed in the doxygen directory.
If the option MBEDTLS_TEST_NULL_ENTROPY is enabled, the cmake generated
makefile will generate an error unless a UNSAFE_BUILD switch is also enabled.
Equally, a similar warning will always be generated if the Makefile is built,
and another warning is generated on every compilation of entropy.c.
This is to ensure the user is aware of what they're doing when they enable the
null entropy option.
This partially reverts 1989caf71c (only the changes to Makefile and
CMakeLists, the addition to scripts/config.pl is kept).
Modifying config.h in the apidoc target creates a race condition with
make -j4 all apidoc
where some parts of the library, tests or programs could be built with the
wrong config.h, resulting in all kinds of (semi-random) errors. Recent
versions of CMake mitigate this by adding a .NOTPARALLEL target to the
generated Makefile, but people would still get errors with older CMake
versions that are still in use (eg in RHEL 5), and with plain make.
An additional issue is that, by failing to use cp -p, the apidoc target was
updating the timestamp on config.h, which seems to cause further build issues.
Let's get back to the previous, safe, situation. The improved apidoc building
will be resurrected in a script in the next commit.
fixes#390fixes#391
Otherwise we get warnings that some documentation items don't have
corresponding #define, and more importantly the corresponding snippets are not
included in the output.
For that we need a modified version of the "full" argument for config.pl.
Also, the new CMakeLists.txt target only works on Unix (which was already the
case of the Makefile target). Hopefully this is not an issue as people are
unlikely to need that target on Windows.
Previously testing was enabled only if GCC || Clang, and I though this was a
"proxy" for the likelihood of Perl being available. Apparently it was not just
that, since MSVC gives me a lot of errors when trying to build tests.
Let's fix them later, and disable for now.
The data produced by gcov for static inline functions is too unreliable to be
actually useful. Some lines that are covered are not marked as such, some
other static inline functions are completely ignored, and the reasons why do
not look obvious.
On Xcode 4.x and above (I tested Xcode 4.6.3 on 10.7.5 and Xcode 5.5.1 on 10.9.2), cmake (2.8.12.2, whether from MacPorts or from clang.org, FWIW) is detecting /usr/bin/cc as Clang, but CMAKE_COMPILER_IS_CLANG is not getting set, so the tests aren't being built. (There may have been other build problems as well, but the fact that the tests weren't being built was by far the most obvious problem.)
Checking the compiler ID detected by cmake, rather than the name of the command used to invoke the compiler, fixes this.
Adding optimization level to CMAKE_C_FLAGS is intrusive and problematic
with policies of various distribution.
However, setting "-O2" in CMAKE_CFLAGS_RELEASE is fine and only
affects release build.
