Open ompadu opened 3 years ago
Hello @ompadu ! Yes I faced a major roadblock with pypi not accepting the wheels due to a file size limit. I requested a limit increase but so far no response. In the meantime, try building from source cloning the repository and its submodules.
I'm in the process to rewrite a major portion of the c++ bindings with cppyy. When its ready I'll try to release wheels for Python 3.9 and deprecate 3.6.
Thanks for your patience.
Thank you for the answer. No problem, I am in no big rush,
Hate to bump this when it's known that something already needs to be fixed, but I wanted to mention that it's not possible to build the repo and it's modules using the readme. Hoping to help someone or possibly get someone up to my current block to look further into it.
The readme suggests to run pip setup.py install
which isn't correct at all, the correct statement should be python setup.py install
. This is because setup.py
can't be used as a parameter for pip.
On attempting to install, however, I get an error in setup.py stating that there's no module named skbuild. scikit-build is a dependency on setup.py and isn't installed by default.
After attempting this however, I get issues with skbuild, which states that there's a problem with cmake on my machine. I installed cmake from chocolatey, which wasn't directly suggested in the readme but is an easy mistake to make as the readme states to use chocolatey to install an out of date version of visual studio.
it should be made clear in the readme that the versions of cmake, make and ninja that are installed should be installed through pip, not chocolatey.
After correcting the issue however, scikit-build makes it clear that there's no generator - hence the readme stating to install visual studio 2017 and to call vcvarsall.bat. However, after installing vs2017 community with chocolatey and attempting to call the vc vars setup script, it's suggested that it doesn't exist. Looking into it, vcvarsall.bat never existed in vs2017 and is a vs2015 only feature. The suggestion for python users is to... use a wheel instead.
In lieu of a functioning wheel, I started trying to find the alternative command for this, which is call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat" -arch=x64
to set up these vars.
This functions properly... until I try building the repo.
Attempting this causes tons of CMake errors due to not having the Windows 8.1 SDK. Yikes. Not a good look.
After installing the Windows 8.1 SDK through the visual studio installer... LibClang can't be found. This is apparently needed to build cppyy.
Instead of trying to figure out what wonky dev setup allows LibClang to be pulled out of thin air, I ended up running pip install cppyy
to intervene.
After that, I got an error from ninja stating that dependencies/bgfx/.build/win64_vs2017/bin/bimgRelease.lib is needed. The dependencies tree while building doesn't include this but includes one for win32 instead. Either this is a misconfiguration in the CMakeLists file or further clueing is needed to get the 64 bit version of bimgRelease.lib to compile. My fix for this was to change the version that is actually used by cmake in cmakelists.txt (changed this to win32) as I don't know how to force the win64 version to build instead. I think this is due to the 64 bit version being the only one supported for a while, with 32 bit releasing later and becoming the default. https://github.com/fbertola/bgfx-python/blob/f83c43c37362b9462abd4b277c13f24477e3e63e/src/CMakeLists.txt#L38
And lastly, this is where I hit a hard wall.
Ninja started failing due to an improperly formatted command generated by FindCppyy.cmake. It's very clear that this cmake file was never meant to be used in its current state, especially since it's located in the experimental folder of the official ROOT repo for Python's rootcling implementation: https://github.com/eric-erki/The-official-repository-for-ROOT/blob/7e47c421a88fdd75b7dce058ece9b4f31135b41b/bindings/pyroot_experimental/cppyy/cppyy-backend/cling/python/cppyy_backend/cmake/FindCppyy.cmake
There's a lot more prerequisites to building, most of which have come out morphing visual studio distributions and bad recommendations on behalf of building this from source. As the only other set of recommended python bindings for BGFX are also practically non-functional, we're left with kinda a hot mess of no real python support in bgfx.
I'd be interested to know where we're at, if anywhere on the proposed rewrite. I think it's a really bad look for BGFX to have this listed on their page and have it be practically nonfunctional.
edit: Might be related to #8, missing binary wheels for python 3.9 and it tries to build it from source.
original post: Ran the following command
pip install bgfx-python==1.0.4 --user
in the VS2019 command prompt with the output (replaced my actual user name with<user_name>
):