split libpolymake_julia into separate repo

[benlorenz]

libpolymake-julia lives here: https://github.com/oscar-system/libpolymake-julia
I have deployed a first set of binaries: https://github.com/benlorenz/libpolymake_julia_jll.jl

advantages:

• this should fix any GLIBCXX errors
• removes the need for the xcode workaround
• recommended by cxxwrap and a further step towards Pkg artifacts
• faster installation as no compilation is needed

disadvantages:

• disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths
  one could try to install a custom polymake + libpolymake_julia into deps/usr after installing the binaries once, as long as all products are satisfied this should not be overwritten
• I have no idea about compatibility with different cxxwrap versions, we cannot really provide binaries built with different libcxxwrap-julia versions, so probably this will pin us to 0.11, github actions will hopefully tell us more

[saschatimme]

disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths

Does this mean you cannot point to your own local polymake installation anymore?

[benlorenz]

disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths

Does this mean you cannot point to your own local polymake installation anymore?

unfortunately yes, at least for now
using your own polymake installation will also require having your own libpolymake-julia installation

[benlorenz]

so according to github actions both cxxwrap 0.11 and cxxwrap 0.10 work, but 0.9 complains about a missing symbol. not really surprising since we built the library with latest libcxxwrap 0.8 (from cxxwrap 0.11).
I guess we can drop support for 0.9.

[benlorenz]

For a custom installation we need to have the path to a libpolymake-julia installation (containing shared library + type_translator.jl) but currently we also need the path to the corresponding polymake installation to run the json generator script. We also use the perl binary that corresponds to that polymake installation at the moment but maybe we don't really need that.

I thought about running the script via the shared library but we need to run that at precompilation before the library is really available. Maybe we could build a tiny script-runner executable linked against the same polymake (built together with libpolymake-julia) that we can use instead. Then we (hopefully) don't need any path apart from the prefix of libpolymake-julia.

[benlorenz]

Weird, it seems that github actions was faster than github ... the run https://github.com/oscar-system/Polymake.jl/actions/runs/160331645 should not have succeeded but it used an older commit instead of the one that it refers to ... there is an undefined variable polymake_run_script in Polymake.jl that will come from a newer libpolymake_julia binary.

edit: maybe this was something like this: actions/checkout#237

[benlorenz]

I was trying to remove the builds for different libstdc++ versions, but maybe this causes the segfaults of the script runner (luckily I get them on my laptop as well, but not every time). Especially since this doesn't happen on MacOS which uses libc++ instead.

[kalmarek]

uuu, all green! :)

[benlorenz]

I was slightly surprised myself, no errors, even without separate builds per gcc / libstdc++ version. The previous crashes were coming from a missing shell enable in the script runner.

There are still a few things that I want to do:

• support custom path for libpolymake_julia, with the new script runner we just need this directory and no explicit path to perl or polymake.
• we might need to store the libcxxwrap-julia version that was used at build-time (e.g. for the check at the end of src/setup_types.jl
• we need some versioning and tests for libpolymake_julia, and then some version check
• maybe more?