search

conda-forge / vtk-feedstock

A conda-smithy repository for vtk.
BSD 3-Clause "New" or "Revised" License
13 stars 64 forks source link

Try re-enabling OSX (Python 3.x) #34

Closed patricksnape closed 7 years ago

patricksnape commented 7 years ago

Since Travis now has two cores this might work again (since Ninja automatically builds in parallel)

conda-forge-linter commented 7 years ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Korijn commented 7 years ago

Would you mind also opening a PR for the second master branch for py27?

jakirkham commented 7 years ago

Also needs a re-render to get the .travis.yml file back and thus start the Travis CI build.

patricksnape commented 7 years ago

It's weird, it's like it's even slower with two cores - older builds used to get to the copying phase before running out of time. Although, this does contain the newer OpenGL2 stuff so maybe that is much slower to build?

Korijn commented 7 years ago

I sure would like to see this thing pass for once... I doubt we can make the build even faster without more trial-and-error fun with cmake parameters... perhaps some Kitware devs could give us advice? Maybe there are some less important groups of VTK modules that we can disable to shave off some build time?

jakirkham commented 7 years ago

Went ahead and started a fresh attempt in PR ( https://github.com/conda-forge/vtk-feedstock/pull/42 ).

Edit: Did this as we have combined Python 2 and Python 3 together in one branch again (and wanted a fresh PR to start 😜). Hope that is ok.

jakirkham commented 7 years ago

I sure would like to see this thing pass for once... I doubt we can make the build even faster without more trial-and-error fun with cmake parameters...

...or some amazing improvements to ninja. 😄

...perhaps some Kitware devs could give us advice?

Not totally sure who to ask. Maybe @jcfr knows some build tricks. 😉

Maybe there are some less important groups of VTK modules that we can disable to shave off some build time?

That also sounds like a good idea. Though I'm not totally sure what to take out ATM. Seems like you guys have already picked the right things at a basic level. Would have to comb through the docs.

We can probably also shave a minute or so if we cache some stuff like the Miniconda installer, possibly conda packages, etc. Though I don't know how much it will help as that stuff ends up on S3 whether Travis CI caches it or if Continuum provides it. This would be a bit exploratory. Though some work has been done on this front.

jcfr commented 7 years ago

knows some build tricks.

Look like you are already disabling testing and examples. You could try to disable MPI related modules.

jcfr commented 7 years ago

Also, effort to support building VTK wheels are happening here: https://github.com/jcfr/VTKPythonPackage

We should be able to repackage the vtk wheels into conda packages.

Similarly to what was done for ITK. See [1][2][3]

[1] https://github.com/InsightSoftwareConsortium/ITKPythonPackage [2] https://blog.kitware.com/itk-is-on-pypi-pip-install-itk-is-here/ [3] https://github.com/conda-forge/itk-feedstock/blob/master/recipe/build.sh

cc: @thewtex

Korijn commented 7 years ago

Repackaging wheels is definitely something we can look into. We're also considering that approach for https://github.com/conda-forge/wxpython-feedstock

Is the wheel repackaging effort sustainable? E.g. what are the odds of the maintainers stopping their efforts in the future?