Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 29 18:45
    o01eg opened #395
  • Sep 29 06:26
    rajhlinux commented #187
  • Sep 20 01:35
    idailylife opened #394
  • Sep 16 13:55
    bernd-K1337 closed #337
  • Sep 16 13:55
    bernd-K1337 closed #345
  • Sep 12 22:43
    berolinux commented #388
  • Sep 06 01:44

    github-actions[bot] on gh-pages

    deploy: 47d5bc76f69e20625214381… (compare)

  • Sep 06 01:43

    stefanseefeld on develop

    Revert "Remove obsolete Jamfile" (compare)

  • Sep 06 01:43
    stefanseefeld closed #393
  • Sep 06 00:58
    stefanseefeld commented on fdd3e8b
  • Sep 06 00:57
    stefanseefeld opened #393
  • Sep 05 17:30
    pdimov commented on fdd3e8b
  • Aug 29 09:24
    dlaugt edited #392
  • Aug 29 08:44
    dlaugt opened #392
  • Aug 24 17:18

    github-actions[bot] on gh-pages

    deploy: 508da1d19890a2430a015a9… (compare)

  • Aug 24 17:02

    stefanseefeld on develop

    Remove obsolete Jamfile Don't attempt to deploy documen… Fix windows CI builds. (compare)

  • Aug 24 17:02
    stefanseefeld closed #391
  • Aug 24 15:26
    stefanseefeld synchronize #391
  • Aug 24 13:02
    stefanseefeld synchronize #391
  • Aug 24 12:46
    stefanseefeld synchronize #391
Tom Kent
@teeks99
I don't believe there is anything you need to do to enable them, but I could be wrong. I didn't have to do anything for my forked repo. Testing the PR is more difficult. Might be easiest to bring that one file in on your own branch in the boostorg/python repo. This, being an infrastructure change, is a bit different than a normal code change.
Stefan Seefeld
@stefanseefeld
OK, thanks for the explanation. I'm experimenting right now with setting this up for the faber project. I'm almost done (Ubuntu and Windows builds are working, still looking into some OSX issues, then comes doc generation).
As soon as all this is working, I'll move on to Boost.Python. I expect to complete this before the end of the year.
Stefan Seefeld
@stefanseefeld
@teeks99 , do you have experience with OSX ? I have set up a workflow (for faber only, for now) for Ubuntu, Windows, and OSX, but the latter produces link errors: https://github.com/stefanseefeld/faber/runs/1583570864?check_suite_focus=true
I wonder whether I missed anything in the Python setup...
Stefan Seefeld
@stefanseefeld
Hmm, I start to wonder: I thought only on Windows do python extensions need to be linked against libpython. The above error looks like on OSX, too.
Tom Kent
@teeks99
I'm definitely not a mac expert. Before my try that failed yesterday morning (see the comment in the github issue) it had probably been a decade since I last worked with a Mac. I think the problem I was having is something similar.
Stefan Seefeld
@stefanseefeld
I think I understand the issue: -undefined,dynamic_lookup is missing somewhere
Stefan Seefeld
@stefanseefeld
Faber migration to github actions is complete (https://github.com/stefanseefeld/faber/actions), now on to Boost.Python. :-)
Tom Kent
@teeks99
Sounds good!
Stefan Seefeld
@stefanseefeld
I have a few comments on boostorg/python#335, and as we are here, perhaps it's easier to do this live...
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.
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.