JuliaPackaging
Add QuantLib
@M-PERSIC was very helpful on slack and indicated that it built on his linux machine, but I ran into more issues locally on Mac. I'm hoping it's not too bad of form to start the PR though?
Looks like there are some Boost library issues plaguing your failed builds. Some fast searching (issue on QuantLib and on Stackoverflow) mention the need to dynamically link the library in CMake which may require either a commandline option enabled or a patch to add in the necessary functions.
clock_gettime requires linking to librt with very old glibc, such as what we use for x86 linux.
@M-PERSIC I was able to get the windows builds to build a static (.a) version with the latest commit, but then the audit at the Julia level the build fails because it's looking for a .so version, I think? Do you have any suggestions?
I was also able to fix the clock_gettime issue.
I took a stab at it. Unfortunately I could not find a way to build the QuantLib shared library for Windows. MingW seems sparsely supported and the current Windows clang wrapper for BinaryBuilder is broken, so for now I think it is best to exclude it as a platform. On the plus side, most other platforms seem to build correctly according to the recipe I put together:
# Bash recipe for building across all platforms
script = raw"""
cd ${WORKSPACE}/srcdir/QuantLib
install_license LICENSE.TXT
mkdir build
cd build
if [[ "${target}" == *-linux-* ]]; then
export LDFLAGS="-lrt"
fi
cmake -DCMAKE_INSTALL_PREFIX=${prefix} \
-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TARGET_TOOLCHAIN} \
-DQL_EXTRA_SAFETY_CHECKS=ON \
-DBOOST_ROOT=${includedir} \
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache -L \
-DCMAKE_BUILD_TYPE=Release \
-G Ninja ..
ninja
ninja install
"""
# These are the platforms we will build for by default, unless further
# platforms are passed in on the command line
platforms = expand_cxxstring_abis(supported_platforms(; exclude = Sys.iswindows))
I didn't have the time to test OpenMP support, so unless you can, then remove the CompilerSupportLibraries dependency as it will be unneeded. Also, some platforms like armv6 build spat out some note: parameter passing for argument of type <...> changed in GCC 7.1 warnings, however it seems QuantLib can handle most gcc versions so it shouldn't be a worry.
Question for the maintainers. Windows is currently excluded because only a static binary could be built. Is a static binary just not compatible with the Yggdrasil/jll ecosystem? Windows is probably the primary platform for QuantLib users and my ultimate goal is to create a Julia package with bindings to QL, so I am interested in understanding what can/can't be done.
Is a static binary just not compatible with the Yggdrasil/jll ecosystem?
Not at all, otherwise the entire BinaryBuilder ecosystem would be totally useless. Whether a shared library is built is solely the choice of the build system you're using. If the developers decided that building only static libraries for Windows was a sensible idea (narrator: it's not) it's entirely on them.
It is building a static library because of this line: https://github.com/lballabio/QuantLib/blob/master/CMakeLists.txt#L151. If you add -DBUILD_SHARED_LIBS=ON to the CMake command, it will then build the shared library on Windows as well. They do decide to forbid shared libraries on MSVC though (I don't understand that part), but that should be fine in BinaryBuilder since we are MingW based.
That said, I did try doing that locally and then it had trouble linking Boost, so there might be more issues buried in their toolchain that need to be sorted out.
Incidentally we do not use MSVC, so perhaps there is narrower work around we could do here
I don't think there is a use for having the testsuite built actually, is there? Boost test is basically a unit testing framework, so it isn't user-exposed, and since we cross-compile, we can't run the tests that are built anyway. So maybe adding -DQL_BUILD_TEST_SUITE=OFF to the build will help remove some of the issues.