ORE-1.8.11.zip missing in release assets
Hi AmitGee,
that‘s right- we provided that additional zip to include the ore.exe binary, but could not this time: Since release 11 we are obliged to run code scans using Blackduck and Coverity, to avoid vulerabilities and license issues. We managed to get that done for the source code only so far, so had to exclude the binary for now. We are thinking about building binaries (for several platforms) using github actions next time, like we do for the Python wheels. If you are looking for quick access to ORE without compiling from sources- please try the Python module for now: You can simply install it with „pip install open-source-risk-engine“. The ORE User Guide shows how you can use that module like the command line executable.
Best wishes, Roland
Hi Roland! I think there are already two workflows, one for linux and one for windows (currently a PR by @kohnech) that build those binaries. They only need to copy the executables into the source tree and zip it.
Hi, in order to close this issue from 1.8.12 on, I'd like to suggest either to
- copy the generated binaries within the build process into
App\\bin\\x64,App\\bin\\Win32(windows) andApp/ore(linux/macOS) as suggested byore_examples_helper.py:
if os.name == 'nt':
if platform.machine()[-2:] == "64":
if os.path.isfile("..\\..\\App\\bin\\x64\\Release\\ore.exe"):
self.ore_exe = "..\\..\\App\\bin\\x64\\Release\\ore.exe"
elif os.path.isfile("..\\..\\build\\App\\ore.exe"):
self.ore_exe = "..\\..\\build\\App\\ore.exe"
elif os.path.isfile("..\\..\\..\\build\\ore\\App\\ore.exe"):
self.ore_exe = "..\..\\..\\build\\ore\\App\\ore.exe"
elif os.path.isfile("..\\..\\..\\build\\ore\\App\\RelWithDebInfo\\ore.exe"):
self.ore_exe = "..\\..\\..\\build\\ore\\App\\RelWithDebInfo\\ore.exe"
elif os.path.isfile("..\\..\\build\\App\\Release\\ore.exe"):
self.ore_exe = "..\\..\\build\\App\\Release\\ore.exe"
else:
print_on_console("ORE executable not found.")
quit()
else:
if os.path.isfile("..\\..\\App\\bin\\Win32\\Release\\ore.exe"):
self.ore_exe = "..\\..\\App\\bin\\Win32\\Release\\ore.exe"
elif os.path.isfile("..\\..\\build\\App\\ore.exe"):
self.ore_exe = "..\\..\\build\\App\\ore.exe"
else:
print_on_console("ORE executable not found.")
quit()
else:
if os.path.isfile("../../App/build/ore"):
self.ore_exe = "../../App/build/ore"
elif os.path.isfile("../../build/App/ore"):
self.ore_exe = "../../build/App/ore"
elif os.path.isfile("../../App/ore"):
self.ore_exe = "../../App/ore"
elif os.path.isfile("../../../build/ore/App/ore"):
self.ore_exe = "../../../build/ore/App/ore"
self.ore_plus_exe = "../../../build/AppPlus/ore_plus"
else:
print_on_console("ORE executable not found.")
quit()
print_on_console("Using ORE executable " + (os.path.abspath(self.ore_exe)))
or
- amend the userguide accordingly to manually do the above, as right now it is not describing a working solution.
I'm open to do 2), but I'd like to hear your opinion...
-regards, Roland
Another issue for the documentation is the mentioned release bundle ORE-<VERSION>.zip and the suggestion that "The release bundle contains the ORE source code, which is sufficient to build ORE from sources as follows..".
First, it's not there since 1.8.11 and second, it is very complicated to use it to build ORE from sources. So again, as stated above, I'd suggest to either
- create such a release bundle again or
- modify this userguide section describing how to create a release bundle manually by copying the executables into their targets and suggesting to always build ORE directly from github (maybe also I'd clarify how to pull the correct tag, especially considering the Quantlib submodule).
Hi Roland, you are right, we need to align this again. We have got github actions now that build command line executables for Windows, Linux and macOS on github. Since these are a bit difficult to find (see https://github.com/OpenSourceRisk/Engine/actions and click on the v1.8.12.0 tag for Windows, for example), I have copied the executables to the release assets here: https://github.com/OpenSourceRisk/Engine/releases/tag/v1.8.12.0), but that means indeed that you have to place them for the examples to work out of the box. I will unpack the zip and tgz bundles and insert the 64 bit Windows executbale in the usual location. Best wishes, Roland
Hi Roland, I have added ore-1.8.12.zip (just this, no tgz, as before) that contains the two Windows executables in the same location as before (App/bin/x86/Release and App/bin/Win32/Release). Best wishes, Roland
Dear Roland, thank you for adding this back, it makes starting with ORE much easier. Concerning the "easy" building of ORE, do you think it's better to also include the patched quantlib to this zip, or is it better to add a description, how to pull the exact version from GitHub, like
git clone https://github.com/opensourcerisk/engine.git oredir
cd oredir
git checkout tags/v1.8.12.0
git submodule init
git submodule update
# EDIT: The following is redundant...
cd QuantLib
git checkout 4afd269627d993f7c35739d055d7151af9d9762c
I wonder whether the ID of the checkout of the submodule can be left out (EDIT: the git submodule update already brings the correct version into the source tree)
This would also prevent situations as in #158, so both adding the patched quantlib and such a description would help.
I've seen that there is a release package for the quantlib module used in 1.8.11 now, directions on including this would be an alternative for the above mentioned inclusion in the zip file, of course there needs to be a release package for 1.8.12 as well.
Also considering the problems in #142 , do you think it's possible to always include Eigen3 in the prebuilt binaries? Or is this not possible in the github actions build?
regards, Roland
Hi Roland,
that's another good point. I have just included the QuantLib tree in ore-1.8.12.zip. That package it is complete now, at least in the sense that it builds for me on macOS, should do for all platforms, but please double check on your Windows machine. And let me know if you see any other gaps.
Thanks, Roland
Hi, everything compiles sucessfully and I also ran example 1. Together with #242 (documentation enhancements) I think we can close this issue.
-regards, Roland
OK, I'll close it for.