Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 30 19:00
    inducer commented #388
  • Jun 30 17:27
    easybob95 opened #388
  • Jun 20 08:29
    kaustubhcs commented #333
  • Jun 10 19:44
    shkoo closed #269
  • Jun 04 03:57
    vitalybuka synchronize #387
  • Jun 04 03:54
    vitalybuka opened #387
  • May 23 14:23
    bernhardu commented #312
  • May 18 09:48
    joriscarrier commented #380
  • May 16 14:15
    glaure commented #386
  • May 16 14:11
    glaure closed #386
  • May 16 14:11
    glaure commented #386
  • May 16 13:35
    glaure edited #386
  • May 16 13:32
    glaure opened #386
  • Apr 26 14:09

    github-actions[bot] on gh-pages

    deploy: a218babc8daee904a83f550… (compare)

  • Apr 26 13:42

    stefanseefeld on develop

    Fix enum_type_object type on Py… (compare)

  • Apr 26 13:42
    stefanseefeld closed #385
  • Apr 26 13:42
    stefanseefeld commented #385
  • Apr 26 13:26
    vstinner commented #385
  • Apr 26 13:20
    vstinner commented #385
  • Apr 25 08:58
    vstinner commented #385
Stefan Seefeld
@stefanseefeld
Hi Tom, sorry I just now saw your messages. Yes, there is an interface at github for squashing. But I really want to exclude the change to the .travis.yml file, to keep things separate. So if you can remove that commit from the PR, we can merge it (with squashing). Moving to 1.75 in a second PR is perfectly fine. There will be a couple of iterations until we get the full coverage (including OSX) that travis-ci now provides.
I'm a bit confused about docker images for windows, as I didn't think docker would run there. (I do know that you can run docker in sort of a Linux VM running on top of Windows, which looks like docker on Windows. But as the goal is to test with MSVC, docker wouldn't be of any help.
Either way, I do know that runs-on: windows-latest is supported, no matter how that's implemented. :-)
Tom Kent
@teeks99
Looks like you got the merges in the right order that the second built on the first?
Stefan Seefeld
@stefanseefeld
Exactly ! :-)
Tom Kent
@teeks99
In addition to being able to run linux docker containers on windows, microsoft has also dockerized their kernel, so you can run "windows containers"....i.e. windows images on a windows server. That's what the links I sent above are doing.
Stefan Seefeld
@stefanseefeld
Thanks for your PRs ! Everything built fine, so now it's time to move on and broaden the coverage to include the other platforms, so we can shut down the travis-ci builders.
Tom Kent
@teeks99
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/
Stefan Seefeld
@stefanseefeld
Oh, really ! Wow, I hadn't expected that. I always thought that docker containers were exclusively based on Linux technologies (cgroups, etc.)
Thanks, happy to learn that Windows takes inspiration from Linux. :-)
Tom Kent
@teeks99
Yeah, MS saw that it was becoming such a big deal, they did corresponding stuff for their OS.
Stefan Seefeld
@stefanseefeld
Right. "If you can't fight them, join them." :-)
Tom Kent
@teeks99
Today's MS isn't the same as the old evil empire.
Stefan Seefeld
@stefanseefeld
so it seems. I still have some deeply rooted skepticism, but I'm happy to be convinced otherwise.
I also shall reach out to other projects I'm involved in (Boost.GIL and Boost.uBLAS) to move away from travis-ci. I think at least Boost.GIL is already mostly using CircleCI...
Tom Kent
@teeks99
Yeah, same, but I work MS in my day job so I have to eat what they feed regardless.... just happy when they make good decisions.
As far as I've heard circleci is doing fine.
Stefan Seefeld
@stefanseefeld
:-)
Stefan Seefeld
@stefanseefeld
@teeks99 do you have docker images for OSX as well ?
Tom Kent
@teeks99
No. I don't think that apple has dockerized mac osx.
Stefan Seefeld
@stefanseefeld
OK, fair enough. I think I have OSX builds set up.
@teeks99 what about Windows ? Do you have containers for the various MSVC versions with boost pre-installed ?
Tom Kent
@teeks99
I've only got a container working with VS2019/msvc-14.2. I hope to get more, but it is a tricky environment.
Stefan Seefeld
@stefanseefeld
OK, that's a great start. Can I simply clone your workflow file and substitute the container name to make this work on Windows, or is there more ?
Stefan Seefeld
@stefanseefeld
@teeks99 what's the name of that container ? Do you already have a workflow yml file that's using it which I could borrow from ?
Tom Kent
@teeks99
I was going to start with teeks99/boost-msvc:14.2, but it doesn't have the boost:python dependencies like the Linux containers in teeks99/boost-python-test
Stefan Seefeld
@stefanseefeld
Ok, thanks. I'll take a look
Stefan Seefeld
@stefanseefeld
does it have boost pre-installed ? In fact, on a tangential note: is there a way to install a (pre-packaged) boost binary package, say, from vcpkg ?
Tom Kent
@teeks99
No, it isn't pre-installed, the goal of that image was to get the tools there to build boost. It is pretty easy to make another image on top of that, where the dockerfile pulls in the source and builds that in the appropriate config(s).
I don't think vcpkg does binaries, I was under the impression it was just a way to build source. Conan might have binaries? We could also just grab the windows binaries from sourceforge.
Stefan Seefeld
@stefanseefeld
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 ?
Tom Kent
@teeks99
Interesting, I've never tried containers with the windows github actions. This might be one of the effects I was fearing when I said that docker isn't fully baked on windows.
Tom Kent
@teeks99
Running C:\Program Files\Docker\Docker\DockerCLI.exe -SwitchWindowsEngine should (might?) make it compatible. Not sure how that would fit into the yaml file though....when that runs vs. when the image starts would have to be coordinated.
Tom Kent
@teeks99
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.
Stefan Seefeld
@stefanseefeld
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.
Stefan Seefeld
@stefanseefeld
(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 !
Tom Kent
@teeks99
vswhere should be at %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe, see
Stefan Seefeld
@stefanseefeld
What is the meaning of %ProgramFiles(x86)% ? Is that a variable substitution ?
what do I need to do to make vswhere be found ?
Tom Kent
@teeks99
That's the variable that on 99.9% of windows computers points to C:\Program Files (x86)\.
Running that at a command prompt would execute vswhere. Otherwise you could set PATH=%PATH%;%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\
Stefan Seefeld
@stefanseefeld
OK, thanks. Do I need to call that set ... in each "run" block ? Or would that be memorized ? (the equivalent of export PATH in bash)
Tom Kent
@teeks99
I'd guess in each one, but honestly I'd just use the full path to the executable.
How many times do you need vswhere?
Stefan Seefeld
@stefanseefeld
That's the problem: faber calls vswhere in each invocation where I need to load an MSVC instance.
(https://github.com/stefanseefeld/faber/blob/develop/src/faber/tools/msvc.py#L203-L206)
So I need a generic solution. I was expecting that an MSVC installation would automatically add vswhere to the system path.