Issues when installing on Windows 10 via Visual Studio Code

[SimonDev666]

Hello, really like the concept you have hear. It is so difficult to get Cling compiled and even then getting it's libraries emebedded into another project. Anyway, i am using Windows 10, latest Visual Studio Code and latest Visual Studio enterprise 2019 + 2022. When i install via pip everything seems to install ok, but when i do the simpliest code in a python file; 'import cppyy', the programs goes absolutely nuts:

PS C:\Users\Simon> & "C:/Program Files/Python311/python.exe" d:/temp/TestCPPYY001.py (Re-)building pre-compiled headers (options: -O2 -march=native); this may take a minute ... In file included from input_line_3:2: In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\string:11: In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\xstring:14: In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\xmemory:16: In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\xutility:12: In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include__msvc_iter_core.hpp:11: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\utility:151:9: error: expected member name or ';' after declaration specifiers !conjunction_v<_Is_implicitly_default_constructible<_Uty1>, _Is_implicitly_default_constructible<_Uty2>>) ^ C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\utility:151:9: error: expected ')' C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\include\utility:150:23: note: to match this '(' ...... Traceback (most recent call last): File "d:\temp\TestCPPYY001.py", line 1, in File "C:\Users\Simon\AppData\Roaming\Python\Python311\site-packages\cppyyinit.py", line 80, in from ._cpython_cppyy import * File "C:\Users\Simon\AppData\Roaming\Python\Python311\site-packages\cppyy_cpython_cppyy.py", line 21, in c = loader.load_cpp_backend() ........ lots more appears here .......... File "C:\Users\Simon\AppData\Roaming\Python\Python311\site-packages\cppyy_backend\loader.py", line 92, in load_cpp_backend raise RuntimeError("could not load cppyy_backend library, details:\n%s" % RuntimeError: could not load cppyy_backend library, details: Could not find module 'C:\Users\Simon\AppData\Roaming\Python\Python311\site-packages\cppyy_backend\lib\libcppyy_backend.cp311-win_amd64.pyd' (or one of its dependencies). Try using the full path with constructor syntax. Could not find module 'libcppyy_backend.cp311-win_amd64.pyd' (or one of its dependencies). Try using the full path with constructor syntax. [WinError 1114] A dynamic link library (DLL) initialization routine failed Could not find module 'libcppyy_backend.dll' (or one of its dependencies). Try using the full path with constructor syntax.

I am at a loss for what to fix or change. i have both watched and read some many docs / vids on how to install, but no-ones seems to have the issues i have hear.

any advice please??

many thanks

Simon

[wlav]

This the same as https://bitbucket.org/wlav/cppyy/issues/382/windows-10-visual-studio-code-cppyy?

Problem is that the latest MSVC isn't yet supported. cppyy 3.0.0 (repo master) does, but still needs 1 more fix before releasing.

[SimonDev666]

many thanks for the reply - i have given up trying to get CLing (LLVM + CLang) to embed in my app - its just maddening complex for what it is and just goes nuts with any config error - but i have embedded python in my test app and this where i hope you excellant approach comes into play - do you have a idea when you might be releasing this new version??

i do have VS 2019, but do not see how this would work, given issues with 2022 - is this an option for me and how would i go about it before your next release??

i have also started looking at Ben Brocks ('reple') alternative approach to a simple embedable c++ type interpreter - when i read about it, it seems such a simple but really good idea - only issue is, if deployed does require a compiler at the our end and this may not always be the case - not a major issue

thats why python is perfect

another quick question - whilst you can use QT within python, could you use QT within the c++ scripts using your approach??

look forward to you next release

many thanks

Simon

[wlav]

cppyy also still requires a compiler, or rather the standard C++ headers and libraries deployed on the client side. Technically, you can get away with just shipping the pre-compiled header (and soon the pre-compiled modules), though. However, in that case, the client-side should explicitly NOT have a compiler installed unless it's an exact version match.

Yes, running from an MSVC 2019 environment should work. The problem is very basic: Clang9, which current cppyy uses, can not parse MSVC 2022 standard headers (which require Clang10 minimum; cppyy 3.0.0 is Clang13).

As for Qt, PyQt is rather solid, so not sure why not go that route once you have Python. But otherwise yes, I don't foresee any problems. Using Qt through cppyy in Python will have other issues as it likely has many constants defined as preprocessor macro's (I actually don't know, but this is common with GUIs), which aren't exposed on the Python side.

[SimonDev666]

i did not know that about cppyy requiring a C++ compiler - is that on installation and setup?? or on each calling cppyy to ingest code?? can i ask how to install cppyy using visual studio 2019 over using visual studio 2022 - using pip??

there was an old demo (10 years old) on github using cling and using QT - you can put QT widgets within the c++ scripts - a good way to learn both c++ and QT

[wlav]

The compiler is there to provide the C++ headers and C++ libraries; the actual compiler (the executable) itself isn't needed. AFAIK, you can't install MSVC through pip. Maybe through conda, but the conda install of cppyy doesn't support Windows atm., and I haven't tried mixing (compilers through conda, cppyy through pip).

Here's one way that apparently works, though: https://stackoverflow.com/questions/64406727/is-there-any-solution-to-packaging-a-python-app-that-uses-cppyy

assuming you're okay with adding the pre-compiled headers (they're kinda big, although still small compared to typical app downloads, I guess), and you have to ensure that versions match or are compatible (true for any C++ application, of course).

For certain features, such as cross-inheritance, the Python development headers (Python.h) are necessary as well.

[SimonDev666]

Had a look at your possible solution - looks complex given i have no idea how your code work or params i would need to use to config - you have put a lot of time and effort into your solution

do you a rough idea when version 3.0.0 of your code will be released??

[wlav]

do you a rough idea when version 3.0.0 of your code will be released??

As soon as I can get this tested on Windows... I'm currently once more struggling once more to get Windows running on VirtualBox on Linux. If that fails, I still have an old Intel Mac laptop that used to run VMWare, which I think I can revive.

Is what it is. Windows is a very difficult platform to support, both because the tooling is limited and access is virtually non-existent.

[SimonDev666]

is there anything i could do to help you - i run on Windows 10 + VS 2019 Ent + VS 2022 Ent + Python 3.11

[wlav]

Right now, I first need to know whether the backend can actually be build as-is, or whether further bug fixes for Windows are needed. C++20 builds for sure don't work (I'll let upstream handle that for now; most of the errors observed are conversion/assignment problems and are likely fixable), so falling back to C++17 when on Windows (for the moment).

You can try: https://cppyy.readthedocs.io/en/latest/repositories.html#building-from-source-1 while setting STDCXX=17.

My build using the virtual machine has been trucking along for over 8hrs now, with no end in sight. For comparison, that same machine, using native Linux, builds the backend in a little over 4mins. I have a functional Windows 10 through VMWare on my Intel Mac, but that has an older MSVC, so the only way for me to test MSVC 2022 atm., is waiting for that virtualbox build to complete ...

[wlav]

Well, build ran overnight, still stuck. In fact, it only shows a spinning circle at the moment, so I can't see where it's at and I can't even kill the CLI within Windows as ctrl+alt+del doesn't appear to work in VirtualBox. I'm going to give up on VirtualBox and try VMWare then, but that does mean I have to start from scratch, so this will take a while.

[SimonDev666]

thanks for doing this - it may mean you do not have enough virtual memory for your VirtualBox VM - my research rig has 16 phyiscal cores (32 virtual) and 128GB of ram - it takes about 1 hour to download and compile CLing / CLand / LLVM to release - about 2 hours for debug - as i said, i would do this for you if you require

[wlav]

I have 64 physical cores and 1TB of RAM on this machine, so that ain't it ...

I'm sure it's some silly setting somewhere, but if I change anything from the defaults, VirtualBox crashes, with the dialog box only showing the title, not the actual message.

I'm now running VMWare, which I should have done from the beginning (just that I was recommended VirtualBox), as it's actually quite decent. I wouldn't call it great, but the device remains responsive when running, which is already quite something.

Unfortunately, although the setup is the same as on VIrtualBox (except Windows10 instead of Windows11Eval), the MSVC compilers can not be found by cmake. Windows really is the gift that keeps on giving. :/ But I do hope that once that is nailed down, the actual build process will be okay performance-wise.

There was this recent contribution: https://github.com/wlav/cppyy-backend/pull/8

I haven't tried it yet and may not for this release in the interest of time, but I hope that once I get to something that compiles and runs correctly on all platforms, doing actual releases may be faster in the future.

[SimonDev666]

sounds like you have a beast of machine, way beyond mine - not used VMWare much, also always VirtualBox - have had some quite complex networking setups in VirtualBox - found it quite stable and that it is FREE

good luck with the build

[wlav]

VMWare's player is free as well for non-commercial use (has been since release 12 IIRC; I used to pay for it and frankly, I still would, given the alternatives).

Performance-wise, there's really no comparison: I gave it 16 cores, 128GB RAM and it completes a release build from scratch in a little less than 16mins. This compares to a bit over 4 mins for Linux with access to the full machine (64 cores, 1TB RAM). I'd go as far as thinking one could even do development this way (16mins is on par with a MacBook M1).

Now, the fact that I have a timing for the build also indicates that yes, building with C++17 works. :) I'll give C++20 one more try and see whether I can fix it myself now that I have a good setup. Otherwise leave it to upstream.

Aside, for my own future reference: the Windows SDK needs to be installed for cmake to find the C/C++ compiler. Not sure whether it's the SDK itself, or one of the components that it pulls it, but there it is. :/

[wlav]

Current repo is a functional C++20 build (64b anyway; 32b still needs to be tried).

[SimonDev666]

does this mean if i pip in visual studio code it should now work??

[wlav]

No; it's not on PyPI yet: Windows comes in 64b and 32b varietals. I'm done with the first (and is the one most folks care about), still fighting the other.

But it builds fine from source (for 64b).

[SimonDev666]

do you have any date for the next release pls??

[wlav]

I was hoping to get the CI up and running and there's always another issue to fix. :) But I cut a release yesterday, please try it.

[wlav]

Closing as no update for a few months (as mentioned 3.0.0 should work fine on Windows). 3.1.0 is now out, too, and Windows builds are now in the CI. Feel free to reopen or open a new issue if there are still issues on Windows.