[WIP] travis: create config

[jcfr]

Adding pip install scikit-build is needed as this is a build time dependency.

For more details, see http://scikit-build.readthedocs.io/en/latest/

Adding pip install ninja will also make this faster build available.

[ghost]

I am aware of that. One thing at a time.

[ghost]

@jcfr So ccache seems to be working as intended. We can cache more aggressively though with these instructions, but I encountered an error while trying to build without the python extensions. Do you know a way around this?

[ghost]

I just realized that the containerized travis isn't going to work because manylinux requires CentOS 5.

[ghost]

Circleci sounds very attractive right now.

[jcfr]

but I encountered an error while trying to build without the python extensions. Do you know a way around this?

The project was put together during the SciPy sprint and it looks like there is a bug ... I will try to have a look by the end of the week.

[ghost]

Thanks.

[jcfr]

I might also attend the VTK hackfest on Monday which would allow me to spend more time on the project. I will keep you posted ..

[jcfr]

Update: I will be working on the VTK wheels Monday

[ghost]

Okay. Maybe I will have something sooner.

[ghost]

Closing for now

[ghost]

So I'm reopening this with a status update:

1. manylinux builds work with ccache
2. osx works theoretically but Travis is backlogged, as usual
3. windows works with clcache, although only Python 3.5 and 3.6 will be supported because Python.org binar

[ghost]

Hrm...chrome appears to crash while attempting to edit the previous post. Not sure what that's about.

[jcfr]

windows works ... although only Python 3.5 and 3.6 will be supported

That makes sense. Since c++11 is now a hard requirements for VTK, compiling it with Microsoft C++ compiler for Python 2.7 is not possible.

Also, I think we can drop 3.3 and 3.4

[jcfr]

I am curious to see if any of the build will timeout

[ghost]

Anyway, what I was trying to say is that Python.org executables require a certain ABI (Python 2.7 requires an ABI provided by MSVC 2008) and VTK requires a minimum of MSVC 2013, which is only provided by Python 3.5 and up.

[ghost]

Appveyor will timeout the first time though. The second time it will use the compiler cache and get a little further. I estimate it will complete the third time.

[ghost]

And also travis will timeout here the first time as well.

[jcfr]

Nice.

The use of the cache to workaround the timeout and speedup the build is neat, that said to generate the release wheels, we still plan on building them on bare metal (aka regular build machine) so that we can do clean builds.

We are also planning on have nightly wheels uploaded as a "latest" github release on a daily basis

[jcfr]

If that helps, while working with powershell and working syntax ... the associated docker image is useful. See https://hub.docker.com/r/microsoft/powershell/

(That said, for the ITK wheels .. we gave up on using power shell and are using python to drive the process. )

[ghost]

All I need to do is kill the python setup.py bdist_wheel before appveyor does so that appveyor can update the cache. But there is literally no way to do that (other than using psutil). I spent three hours trying to do something that took 5 minutes on linux and osx. That is ridiculous.

[ghost]

we still plan on building them on bare metal (aka regular build machine) so that we can do clean builds.

You can do whatever you want, but I should note that builds with clcache/ccache are clean builds. The programs are written so that they are an exact substitute for the actual compiler; the only difference is the time to compile. It's not the same as reusing the CMake cache, which doesn't contain a hash of the compiler input.

[jcfr]

The programs are written so that they are an exact substitute for the actual compiler; the only difference is the time to compile. It's not the same as reusing the CMake cache, which doesn't contain a hash of the compiler input.

Thanks for clarifying.

It makes sense then.

The requirements for this to work is that (build_time + use of up-to-date-cache < CI service timeout) where size of up-to-date-cache is limited by CI service

Cc: @thewtex