Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:52
    linjiahao962889027 opened #389
  • 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
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.
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.
So I need a generic solution. I was expecting that an MSVC installation would automatically add vswhere to the system path.
Tom Kent
@teeks99
Faber should probably use the hard-coded (ish) path. vswhere does not get added to a PATH variable by default on any install, but that location is going to be supported by MS going forward
Or at least have faber check to see if the supported path exists before going on (and using the bare call or failing)
Stefan Seefeld
@stefanseefeld
Yeah, that makes sense.
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 ?)