I think they must match? Try editing the cmakecache.txt to 14.0. This is definitely easier on linux.
I haven’t had this problem running VS directly but I donn’t yet understand how ninja uses the native compiler. What other if any compilers are installed on the machine? The environments should be independent but they’re not. I have 9.0, 11.0, and 12.0 on my system
C:\Program Files (x86)\Microsoft Visual Studio 9.0
Instead of “locate” “dir /s /p” should work, or type in the search box (upper right from the explorer gui)
Also VS builds 32 bit by default. I don’t know if ninja handles the 32/64 bitness automatically. Maybe 64 bit python and 32 bit OCCT or dependencies?
the ninja stuff is copied from the vtk conda recipe… i think it i not necesary to ue it.
oh didn’t see the 32 64 bit mess. i thought windows is a bit easier then llinux-install because win do not have that much different versions…, but it’s definetly not
I will try to install vs 2015 on this computer. But maybe this won’t be possible without admin rights…
as expected this installing vs15 isn’t possible without admin rights… If I have time I will try iunstall a windows with gnome-boxes or directly use appveyor.
Maybe it is possible to install appveyor/cirle ci/travis locally on a virtual machine?
I’ve been following your progress today
A rambling first look based on the Appveyer logs
We must specify the generator for cmake
In the staged-recipes appveyor.yml file they don’t specify a “generator” in the matrix, so we will need to add logic to the bld.bat file to handle this based on the arch and Python version. On this note I noticed that VC14 dependencies are being loaded in a Python 2.7 environment, this is asking for trouble. I wonder why they don’t force a compiler to match the python version in their appveyor.yml file.
tcl and tk I think both haven’t been found. The found .dll’s may also may be a problem as they link to a ruby directory that may or may not be compatible. This is normal. Locally OCCT cmake finds these .dll’s in my git.exe by default. We’ll probably need to pass a lot of paths from the cmake command line. OCCT by default looks in a 3rd Party directory. Can you post a directory listing of the conda tk package?.
make install will not work. We will need to pass command line parameters to msbuild here as well. To complicate things its called vcbuild on VC9 needed for Python27
I also don’t know if OCCT7 will compile with VC9 due to the same C++11 concerns as FreeCAD. Is it possible to disable some of the builds on staged-recipes?
On a more positive note the more I learn about this the more I am convinced. I inherited an old win7 computer that I was planning on turning into a xenial machine, useless for compiling, but maybe I can clean it up and install conda. QT is going to be a killer.
We must specify the generator for cmake
In the staged-recipes appveyor.yml file they don’t specify a “generator” in the matrix, so we will need to add logic to the bld.bat file to handle this based on the arch and Python version. On this note I noticed that VC14 dependencies are being loaded in a Python 2.7 environment, this is asking for trouble. I wonder why they don’t force a compiler to match the python version in their appveyor.yml file.
I only wanted to build with vs15. I didn’t find out how to disable all the others… And I also don’t know why a python version is mentioned there. The build shouldn’t be dependent on python. But maybe this is the way to disable the wrong builds:
build:
number: 0
skip: true #[not py35]
tcl and tk I think both haven’t been found. The found .dll’s may also may be a problem as they link to a ruby directory that may or may not be compatible. This is normal. Locally OCCT cmake finds these .dll’s in my git.exe by default. We’ll probably need to pass a lot of paths from the cmake command line. OCCT by default looks in a 3rd Party directory. Can you post a directory listing of the conda tk package?.
Library
bin
tk85.dll
tcl85.dll
include
X11
.....
.....
lib
.......
tcl85
......
tk85
.......
make install will not work. We will need to pass command line parameters to msbuild here as well. To complicate things its called vcbuild on VC9 needed for Python27
I also don’t know if OCCT7 will compile with VC9 due to the same C++11 concerns as FreeCAD. Is it possible to disable some of the builds on staged-recipes?
Yep thats exactly what I would like to try… But didn’t find how to do it.
On a more positive note the more I learn about this the more I am convinced.
At the moment I have a bit bad feelings about the whole conda thing because of this graphics dependencies… (see the linux build) Hopefully it’s allowed to install these packages with the ci-system. Otherwise conda-forge will not work.
I inherited an old win7 computer that I was planning on turning into a xenial machine, useless for compiling, but maybe I can clean it up and install conda. QT is going to be a killer.
qt is a killer anyway. I have read about conda developers working on a qt5 package for about 300 hours .
thanks for the patch. I have applied it to a side-branch to not force the rebuild.
I have now tried the recipe on my local linux machine. It does work but uses the system tk. As all platforms have problems with finding the right tk, the best thing will be to apply a patch directly to the occt-cmake. Is there already a mirror of occt? There was a discussion in the ppa-thread to create one on launchpad.
As I understrand: drawexe is only used to create bug-reports for occ. So there is no need for draw-exe and also tk/ tcl for this package. We can add this later on. https://tracker.dev.opencascade.org/view.php?id=27639
regarding track-features: this doesn’t work right now. I don’t know what is wrong.
But I also do not understand this approach. Occt will be build for 6 different python-bit couples. So if I am in a 32bit python3.5 enviroment there will be only one occt package suitable… Why we need to have this additional track-features?
I am going about it wrong. I noticed that in the build logs the vc14 version of the dependencies was being downloaded for all 6 builds. What is needed is to install the proper vc meta package that tracks these features. Then our package should create these features in the meta.yaml so packages building against it can use the proper version. https://github.com/conda-forge/staged-recipes/pull/809 was helpful.
I will have time to make another attempt in a few hours.
-but after that occ-cmake calls “find_package(TCL)” again, and because occ reset all the options previously set it finds the wrong tcl/tk …
I think without the second call this could work… Although the tk variables are not used at all. Only the 3dparty… variables. But there is no message about this variables…
I think there is no way to manage this without patching cmake, because on the build-system we do not have a system-tk (win, mac). So the build will stop when the second call to find_package(TCL) is made.
Just had another look at the windows builds. cmake doesn’t have errors when find_packages(tcl) doesn’t find any tcl/tk. So setting only the 3d-party-tk vars should be enough.
@sgrogan: I have invited you as a contributor to this repo. So if you have any patches please apply them directly to the side branch. You can also rebase the master on the side branch once you are done. This will trigger the ci-systems to start building.
Great thanks!
With your latest builds adding python as a build dep seems to force the correct environment. Notice the correct vc metapackage is installed.
For ex
Python is a fake dep that forces the correct environment. I think making vc-10 (in this example) will do the same without the fake dep. I’ll try this on the side branch.
Locally it takes me a few times through config in the cmake make gui to make everything stick to point at the correct locations. I can experiment locally to find all the paths that must be passed to cmake.
EDIT: cmake gui after getting everything set
Python is a fake dep that forces the correct environment. I think making vc-10 (in this example) will do the same without the fake dep. I’ll try this on the side branch.
Slowly I understand the windows problem. in the tk package they are using ninja to set the right vc version as dependency. maybe we should do the same.
on os x we have some problems with c++11.
see
/Users/travis/miniconda/conda-bld/work/occt-1d505bb/src/Standard/Standard_Handle.hxx:21:10: fatal error: 'type_traits' file not found
Locally it takes me a few times through config in the cmake make gui to make everything stick to point at the correct locations. I can experiment locally to find all the paths that must be passed to cmake.
EDIT: cmake gui after getting everything set
that would be nice. I only set all the ssma variables needed for linux. and i don’t know if I had done this the right way.
.