Hi @teeks99 , I'm trying a Windows workflow (https://github.com/stefanseefeld/boost.python/blob/actions/.github/workflows/test-windows.yml), but get the error "Error: Container operations are only supported on Linux runners" (https://github.com/stefanseefeld/boost.python/runs/1609468749?check_suite_focus=true). Am I misunderstanding what you explained earlier ?
Interestingly, at the end of the page detailing features of the windows image it lists a bunch of windows docker containers as resident in the image....yet it doesn't seem to be configured to run them by default.
OK, so I have started experimenting a bit with Windows. Here is how far I have got: https://github.com/boostorg/python/pull/342/files
There is an action to install MSVC (https://github.com/boostorg/python/pull/342/files#diff-9e2bbc2329bfb445d0985173b98e981dd7fbf69428e7addd83d453e8d5f3ff2dR15). However, I was expecting this to also make the
vswhere tool available, but faber then can't find it, so the build fails: https://github.com/boostorg/python/pull/342/checks?check_run_id=1612000557
Any idea how to fix this ? I thought
vswhere is bundled with MSVC nowadays.
(For now I'm installing boost prerequisite libs via vcpkg (https://github.com/boostorg/python/pull/342/files#diff-9e2bbc2329bfb445d0985173b98e981dd7fbf69428e7addd83d453e8d5f3ff2dR19-R22). Still need to figure out how to cache things properly so they don't get recompiled each time. It takes half an hour to build without caching...
and I completed the transition away from travis-ci by adding a workflow for OSX and another one to build and deploy Boost.Python documentation.
@teeks99 thanks again for kicking of that work !
what do I need to do to make
vswhere be found ?
Running that at a command prompt would execute
vswhere. Otherwise you could set PATH=%PATH%;%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\
How many times do you need vswhere?
So I need a generic solution. I was expecting that an MSVC installation would automatically add
vswhere to the system path.
Or at least have faber check to see if the supported path exists before going on (and using the bare call or failing)
So just to be entirely sure I understand: There is indeed a variable called "ProgramFiles (x86)" on Windows, which gets substituted approrpriately when evaluating e.g.
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\ in cmd.exe ?
(and in 99% the value of the variable is identical to the name of the variable ?)
The shell variable %ProgramFiles(x86)% points to C:\Program Files (x86) on almost all computers, I'm guessing a very small percentage have a non C: drive as their default.
From my understanding VS 2017 (15.2+) and VS 2019 will always install vswhere to %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.
Hi @teeks99 , I'v run into a curious problem: To extract header dependencies from MSVC I run
cl /nologo /showIncludes /EP ..., then I scan the output (stderr !) for "Note: including file: ". I just realized that this only works for English locales. Do you know of a way (under Windows) to set the locale just for a specific subprocess (such as cl ...) ?
Hii Everyone! I'm a first year B.Tech Electronics and communication engineering student. I would like to start contributing to Boost C++ libraries as I highly intereseted in Coding as well as development and also want to participate in GSoC 2021 under this Organisation. Will somebody help me?
Hello, and welcome ! The very first step is to get set up with Boost as a development platform, i.e. be able to compile it (or at least, the subset of it you are interested in), and work your way through the various examples. Once that's done we can talk about any specific interest(s) you may have.
Hi, I think I've run into this alignment issue: boostorg/python#27 and since there aren't many comments I'm wondering if the referenced but unmerged PR (boostorg/python#35) already fixes it, or if there is further work required. Does anyone know more details? Thanks.
hi @pacidic , I have been looking into boostorg/python#35 , especially rebasing it to make it compile with current master, but eventually stopped as I realized that this PR seriously breaks backward compatibility, at least for people who write custom converters.
While I'm still thinking about ways to fix boostorg/python#27 without such breakage, I wonder: can you solve your problem by using a
While I'm still thinking about ways to fix boostorg/python#27 without such breakage, I wonder: can you solve your problem by using a
shared_ptr (either std:: or boost::) as HeldType ? Wouldn't that solve the issue, as in that case the type would always be allocated on the heap on a correctly aligned memory boundary, rather than being forced into a specific location in the pre-allocated PyObject ?
hi @stefanseefeld, thanks for looking into it. Indeed, using the
shared_ptr held type idea you mentioned has worked for fixing some alignment-related crashes in the past. However, as in the original issue, the error also seems to occur in bound member functions that return Eigen::Matrix types, which are converted to numpy arrays via custom converters. The key part of the conversion to python is the call to numpy::from_data, followed by a copy(). I'm wondering if the issue is there, I need to look into it.
I was always irritated by Eigen and its strange handling of alignment. Why does it require user code to do anything special (e.g. https://eigen.tuxfamily.org/dox/group__TopicStructHavingEigenMembers.html), rather than adding the
alignas() attribute to its types directly ?
And worse: why doesn't it contain checks that allow it to conditionally dispatch to non-vectorized implementations if the object happens to be un-aligned , rather than crashing ?
I can see
Boost.Python 's use of placement operator new as being problematic, as that overrides a type's alignment requirements, so that's one of the things I'm looking into fixing now.
Hi @teeks99 , I'm running into a build issue on a new PR (boostorg/python#360). The reason (I believe) is that the builds use your
boost-python-test-docker docker image, which installs boost prerequisite libs via bcp python. As it happens, my PR adds another prerequisite (boost.align), and thus the build fails as that isn't installed. I'm not sure what the best is to solve this. Would it make sense to modify those docker images to install all of boost (and perhaps remove boost.python, to avoid potential conflicts), rather than only what the old boost.python would depend on ?
by the way, @pacidic, boostorg/python#360 is my attempt to fix the alignment issue (this is a reworked version of boostorg/python#35). It's still WIP until I have sorted out the build issues, but it works fine for me locally with g++ 9. I haven't tried to build any Eigen extension modules, though.