Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 31 21:21
    ijnek commented #359
  • Jul 31 21:20
    ijnek commented #359
  • Jul 31 21:20
    ijnek commented #359
  • Jul 21 19:18
    DragonOsman edited #390
  • Jul 21 18:14
    DragonOsman edited #390
  • Jul 21 18:13
    DragonOsman edited #390
  • Jul 21 18:12
    DragonOsman edited #390
  • Jul 21 18:11
    DragonOsman opened #390
  • Jul 19 15:55
    Osyotr commented #384
  • Jul 18 16:40
    Nekto89 commented #225
  • Jul 13 20:17

    github-actions[bot] on gh-pages

    deploy: 8dd151177374dbf0aa5cb86… (compare)

  • Jul 13 20:13

    mclow on boost-1.80.0.beta1

    (compare)

  • Jul 04 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
Stefan Seefeld
@stefanseefeld
Can you squash all commits into one, but leave out the change to the appveyor config ? That way the PR will be a single commit, adding a single file. Also, as you said yourself, the 1.66 release is rather old, so perhaps this would be an opportunity to move to a more recent boost release as baseline ? (only if this is easy and quick to do)
Otherwise this looks great, and I'm really thankful for your help with this.
(I would actually like to clone this workflow as soon as it's committed to run OSX and Windows builds. Once that's done, we can decommission travis-ci as well as appveyor.)
Stefan Seefeld
@stefanseefeld
@teeks99 (^)
Tom Kent
@teeks99
Is there not an option in the pull request to squash the commits? If not, you may need to turn that on for the repo.
I wanted to get things working first, then I'll put out another pull request to move to 1.75. Also, I'm still having a small issue getting 1.75 to BCP correctly in my docker image, so I want to get to the bottom of that.
OSX and Windows will look a lot different. I don't believe there is any way to run docker images with OSX, so we'll need to do all of that setup logic in boost::python's workflow. As I mentioned in the boostorg/python#334 issue, I've got a branch started with Mac OSX support, but I'm having serious problems with it. You want to have a look and see if you have any ideas?
Tom Kent
@teeks99
For windows, docker images are supported, but the environment isn't quite as settled as docker on linux. I do have a VS2019 docker image (src), but it isn't quite ready for prime time...and I don't have any older versions dockerized yet. I'd vote that we stick with the windows image from github for now. Plus Appveyor is still working fairly well, so this isn't quite as urgent.
On that note, the appveyor scripts are tied to exact version numbers of visual studio...which was breaking when the appveyor people updated their image. Is there a way to only specify the major version of visual studio (or the msvc toolset, i.e. 14.0, 14.1, 14.2)? I'm not familiar with fabers toolset lookup options.
There is a very simple pull request for appveyor waiting out there that simply rolls the VS2019 version from 16.8.1 to 16.8.3....but that's a losing battle. We'd need to update every few weeks.
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