When we introduce block scoping, using variables declared in a more
narrow scope from a block with wider scope will fail. Warn about
these so people can avoid it and fix their code.
While I do not agree with the idea of using straight assignments in
the condition of a for loop, people are divided on the argument and
lots of old code uses it.
When cross-compiling c4group should be build for the host
machine before building OpenClonk for the target.
Without C4GROUP_TOOL_ONLY option, we have to build OpenClonk
for the host.
C4GROUP_TOOL_ONLY allow to build only c4group tool for the
host.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
With this patch I can build OpenClonk with Buildroot.
While cross-compiling, it is easier to find a binary
from the patch using FIND_PROGRAM instead of using
a cmake file.
Try to find c4group native tool with FIND_PROGRAM and
fallback to the cmake file if c4group is not found.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
As reported by [1], some distributions use shared libraries as
default preset in CMake.
Without explicitely linking statically libmisc and libc4script,
we have the following link issue:
[...]/host/bin/x86_64-linux-g++ --sysroot=[...]sysroot
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os
-std=gnu++14 -Wall -Wextra -Wredundant-decls -Wendif-labels
-Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Winit-self
-Wsign-promo -Wno-reorder -Wno-unused-parameter -Wnon-virtual-dtor
-Woverloaded-virtual -DNDEBUG
-rdynamic CMakeFiles/c4group.dir/src/c4group/C4GroupMain.cpp.o
-o c4group
-Wl,-rpath,[...]/build/openclonk-7.0:
liblibmisc.so -lz -lpthread -lrt
liblibmisc.so : référence indéfinie vers « C4LangStringTable::Translate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const »
liblibmisc.so : référence indéfinie vers « C4LangStringTable::system_string_table »
[1] https://github.com/openclonk/openclonk/pull/26
While at it, build libopenclonk statically since libopenclonk is not
installed by the CMake build system.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
FatalError(Format(...)) was necessary previously. Actually it seems not
like a huge thing, but being able to format the string directly in
FatalError is a lot more convenient.
Renamed and documented the former function SetNextMission. Added a script wrapper for the old function that issues a warning. Renaming is based on the fact that the docu speaks of scenarios, and other functions, such as GainScenarioAchievement already use this terminology
Nicolas Hake