pip use from pyozw_setup.py should be replaced.
veleek opened this issue · 7 comments
According to the pip user guide (using pip from your program), calling pip directly from a python program is unsupported.
As best as I can tell this has been true since pip 10.0.0.0 and should be replaced with pkg_resources and/or setuptools if possible. Currently, if you try to run setup for python_openzwave on windows it'll complain about missing dependencies (even if they're installed) and then fail to install them due to the fact that 'main' is not exported from pip anymore.
I'm willing to look into making this change if this seems reasonable to change.
The build system needs some refreshing since python_openzwave has been around there have been many changes and additions to both distutils and setuptools. I believe that setuptools now has the ability to do a temporary install of a library if the library is only needed for the build process and not needed during run time. I created a framework for a more efficient and easier to read build system. it is included in #152. There is still more that needs to be done as far as the framework is concerned But the bulk of it is there.
Because there is not so much of a concern with API breaking changes in the next release there might be some changes to the build system.. I do not know yet. we have a pretty massive code change I have been working on that is really going to make using python_openzwave a lot easier. I am not sure how much @bibi21000 is willing to change or how much longer he is willing to wait before the next release. Which reminds me I should put some hours into documentation this evening.
I did also want to mention.. pip always complains about something. Most times it is because it's not the most recent version but they are releasing new version pretty quickly so it is hard to stay up to the minute with their changes.
Ah shoot. I did see #152, but I thought that it was already merged but I didn't see what branch it was in. I just assumed that it was master and was looking at it there.
Like you, I'm trying to get everything to build properly with Windows, so I'm looking forward to these changes. Feel free to close this bug if the changes you've made make this mostly redundant.
if you use the 0.5.x (has the most up to date code) branch then it should build perfectly on Windows. It was a complex thing to get that to work right. because both distutils and setuptools do not support all MSVC compiler versions and is also not the best as far as setting up a build environment for Windows, The PR I did supports all MSVC Compilers from 8.0 to present. including the VS Build Tools, which is just the essentials to compile C/CPP code without the need for installing the whole Visual Studio IDE. All versions of the .NET framework Windows SDK 6.0 to present. all versions of .NET FX. all versions of HTML Help. and a whole mess of other things. It will auto detect what you have installed and creates an identical build environment to what the IDE creates. It uses 10 threads to compile libopenzwave so the whole process takes about 2 minutes depending on machine resources.
Even tho the code I wrote will support all MSVC compilers you will need to have MSVC >= 12 installed. There is some code in the Cython portion of python_openzwave that has syntax that earlier versions of MSVC doesn't like. Easiest thing is to get the latest VS Community Edition. the latest Windows 10 SDK. and you should be able to compile without an issue.
To install:
python setup.py install --flavor=dev
To build:
python setup.py build --flavor=dev
If you have a Sigma based ZStick you do not need to pass any parameters to the option.ZWaveOption class. It should hash all of this stuff out including the com port for the zstick. if you have an issue let me know. remember to call the lock method on the instance of option.ZWaveOption before passing it to the network.ZWaveNetwork constructor
correction... If you want to use the auto detect of the zstick then you will need to have the serialport library installed. if not just pass COM* to options.ZWaveOptions. it handles modifying the comport you pass so it will correctly address the namespace virtual file pointer.
Haven't tried running anything yet (time for bed!) but the build worked GREAT! Much cleaner and easier than before. Two things:
- I was trying to build against the openzwave
devbranch, and I got build failures:
<other happy compiling steps...>
compiling ValueID_test.cpp...
C:\code\GitHub\veleek\python-openzwave\openzwave\cpp\test\ValueID_test.cpp(28): fatal error C1083: Cannot open include file: 'gtest/gtest.h': No such file or directory
<continued to attempt to link and build libopenzwave>
Instead of continuing and attempting to link, this should probably just stop here and die. I don't know exactly why it can't find gtest.h. Maybe there's some config I need to update on my side or change in openzwave\cpp\test\Makefile or something.
- Second, on the successful build (after I just deleted the test folder from openzwave), I got a few output messages for potential optimizations or fixes. I'm not sure familiar with C/C++ builds so I don't know if there's anything actionable here, but just giving them out in case they're useful to you.
compiling ValueBitSet.cpp...
compiling ValueBool.cpp...
compiling tinystr.cpp...
Microsoft (R) Library Manager Version 14.15.26730.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
Microsoft (R) Library Manager Version 14.15.26730.0
Copyright (C) Microsoft Corporation. All rights reserved.
Use cached build of openzwave
running build_py
Distribution.get_command_obj(): creating 'build_py' command object
running build_ext
Distribution.get_command_obj(): creating 'build_ext' command object
cythoning src-lib/libopenzwave/libopenzwave.pyx to src-lib/libopenzwave\libopenzwave.cpp
building 'libopenzwave' extension
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT -DPY_LIB_VERSION=0.4.18 -DPY_LIB_FLAVOR=--flavor=dev -DPY_LIB_BACKEND=cython -DCYTHON_FAST_PYCCALL=1 -D_MT=1 -D_DLL=1 -DPY_SSIZE_T_CLEAN=1 -DPY_LIB_FLAVOR=dev -DPY_LIB_BACKEND=cython -Isrc-lib\libopenzwave -IC:\code\GitHub\veleek\python-openzwave\openzwave\build -IC:\code\GitHub\veleek\python-openzwave\openzwave\cpp\build\windows -IC:\code\GitHub\veleek\python-openzwave\openzwave\cpp\src -IC:\code\GitHub\veleek\python-openzwave\openzwave\cpp\src\value_classes -IC:\code\GitHub\veleek\python-openzwave\openzwave\cpp\src\platform "-Ic:\program files (x86)\microsoft visual studio\shared\python36_64\include" "-Ic:\program files (x86)\microsoft visual studio\shared\python36_64\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\cppwinrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17134.0\winrt" /EHsc /Tpsrc-lib/libopenzwave\libopenzwave.cpp /Fobuild\temp.win-amd64-3.6\Release\src-lib/libopenzwave\libopenzwave.obj /Gy /O2 /Gd /Oy /Oi /fp:precise /Zc:wchar_t /Zc:forScope /EHsc /wd4996 /wd4244 /wd4005 /wd4800 /wd4351 /wd4273 /FS /Zc:inline
libopenzwave.cpp
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /nodefaultlib:libucrt.lib ucrt.lib /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO "/LIBPATH:c:\program files (x86)\microsoft visual studio\shared\python36_64\Libs" /LIBPATH:C:\code\GitHub\veleek\python-openzwave\venv\libs /LIBPATH:C:\code\GitHub\veleek\python-openzwave\venv\PCbuild\amd64 /LIBPATH:openzwave\build\lib_build "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x64" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\lib\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.17134.0\ucrt\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.17134.0\um\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x64" setupapi.lib msvcrt.lib ws2_32.lib dnsapi.lib Python36.lib OpenZwave.lib /EXPORT:PyInit_libopenzwave build\temp.win-amd64-3.6\Release\src-lib/libopenzwave\libopenzwave.obj C:\code\GitHub\veleek\python-openzwave\openzwave\build\lib_build\OpenZWave.lib /OUT:build\lib.win-amd64-3.6\libopenzwave.cp36-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.6\Release\src-lib/libopenzwave\libopenzwave.cp36-win_amd64.lib
Creating library build\temp.win-amd64-3.6\Release\src-lib/libopenzwave\libopenzwave.cp36-win_amd64.lib and object build\temp.win-amd64-3.6\Release\src-lib/libopenzwave\libopenzwave.cp36-win_amd64.exp
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
Generating code
Finished generating code
I'm running on Windows 10 v1803 (Build 17134.706) and I have Visual Studio 2017 installed and pretty much every SDK. Full build output for the successful build here: python_openzwave-build.log
everything looks ok in that build. the macro re definitions I would not worry about the LIBCMT thing is the first time I am seeing that. I will research it. I am not a C guy either.
I went through and did some more "tweaking" of the setup program. PR #182.
As far as the optimizations are concerned I would not worry about them. Unless I wright a complete build system and remove any reliance on distutils I am not going to be able to change those compiler arguments to be rid of them. as far as the link warning LNK4098 it does not appear to effect the program at all and I do not believe warrants any investigation at this time.
as far as compiling the dev branch of OpenZwave, more times then not it will fail. The dev branch is a WIP branch and is almost always going to have issues. Once all problems are sorted then the relevant changes made are merged into the master branch. The master branch is not the same code that is in the last release of OpenZwave. That being stated, if you use this command python setup.py build --flavor=dev it will download the code from the master branch of OpenZwave and compile it without installation. This command will do an install python setup.py install --flavor=dev