Users, who try to compile keep tripping over it, despite documentation
in the INSTALL file. Also, autoconf-archive might be hard to install
for users, who opted not to use MSYS2 and stick to MinGW only.
This commit bundles macros:
AX_CXX_COMPILE_STDCXX (version/serial 10)
AX_CXX_COMPILE_STDCXX_11 (version/serial 18)
When using C++11 code that can possibly throw exceptions (such as
std::make_shared(...) linking libstdc++.a using Clang on MSYS2
will generate errors such as:
libstdc++.a(eh_personality.o): duplicate section
`.rdata$_ZTSSt9exception[_ZTSSt9exception]' has different size
Although potential suggested fixes involve allowing duplicate symbols,
-Wl,--allow-multiple-definition, this solution can introduce unexpected
behavior when one symbol clobbers another symbol.
To solve this, switching to dynamic linking of the libstdc++ library
appears to be all that's needed.
This works out of the box on Linux and MSYS2, but does not work on
macOS - Xcode supplied make does not support this option, so GNU make is
used instead.
Unfortunately, adding new package on macOS did not invalidate the cache,
this package removes the brew cache from macOS job to avoid this problem
in the future.
Fixes: #53
Until now the build and package scripts have supported
several architectures, compilers, build types, package-managers,
and bit-depth targets.
The code might be maintainable if left as-such, however we have plans
to continue expanding the number of architectures (ARM, PPC, ... ),
operating systems (Android, BSDs, ...), and build variations
amung those.
The scripts (regardless of language) would only grow in complexity
as more variations are added. Thus, we needed a solution that can
scale without adding complexity.
To achieve this, the scripts were refactored as follows:
- all "data" was moved out of code into configuration files
- A back-end "Automator" engine was written to parse the
data based on generic variables fed to it by a front-end
script
- build.sh and list-packages.sh were re-authored as thin front-end
scripts that drive the automator
- Their CLI's were retained so there has been very little change
needed to the CI invocation lines. The only changes have been to
clarify the existing arguments improved based on feedback, ie:
--build-type release, --build-type debug instead of fast, small
