Can't install pyinsane2

[Masaaq]

While installing via pip install pyinsane2

returns message

    cl : Command line warning D9025 : overriding '/DNDEBUG' with '/UNDEBUG'
    properties.cpp
    c1xx: fatal error C1083: Cannot open source file: 'pyinsane2/wia/properties.cpp': No such file or directory
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\cl.exe' failed with exit status 2

I understand that it can't find the properties file, but I don't know how to fix this.

Thanks in advance

[jflesch]

It's weird. It should work.
I'm going to try as soon as possible .. which may not be before a week or two .. :/

Anyway, in the meantime, what you can try is:

• clone the pyinsane repository locally
• run "python ./setup.py install" in it

This is the way I install it.

[Masaaq]

Thanks for reply!

pyinsane2/wia/properties.cpp(3) : fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory

ried to do it manually, now it gives me this one.

[jflesch]

Hm, weird. stdint.h is a standard C header (not a C++ one however). Just to be sure: Does your installation of Visual Studio includes all the C and C++ tools ?

Pyinsane has to mix C and C++ (C++ to access the scanner using WIA2, and C for Python bindings). You will also need Windows Driver Kit.

[jflesch]

Hm, stdint.h may actually be provided by WinDDK (I don't have a Windows computer available right now so I can't check).
If so, the problem may be related to WinDDK location.

setup.py assumes that, by default, WinDDK is installed in c:\winddk\7600.16385.1. Which is unlikely to be your case I guess.
You can define the following environment variables to fix that:

• WINDDK_INCLUDE_DIR (default value: c:\winddk\7600.16385.1\inc\atl71)
• WINDDK_LIB_DIR (default value: c:\winddk\7600.16385.1\lib\ATL\amd64)

[jflesch]

b0a5c2d

[jflesch]

BTW, I forgot to ask (sorry), but when you did install visual studio, did you install the C dev tools (headers, etc) ?
For reference, I'm working with Python 3.4, therefore I installed Visual C++ 10 and not 14.

[OddlyDoddly]

My friend is also having this issue verified he's installed cpp build tools for visual studio 14

[jflesch]

As I mentioned before, it's a C header, not a C++ one.

It seems it's now part of the Windows SDK and is not included anymore in Visual Studio:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0f580a73-6f11-4aa6-abbe-6bf1438734c2/standard-files-stddefh-stringh-missing-in-visual-studio-2015-rc#de6385c2-63bf-4a02-a7dc-77972f98ab07
https://social.msdn.microsoft.com/Forums/vstudio/en-US/cfa48739-cd32-43d2-9d27-2b6653da6645/canf-find-standard-c-header-file-in-visual-studio-2015-community-version#38b883ab-1918-470d-8565-673d85a0ffc0

I'll update the documentation when I have time.

[Maier123]

Had the same issue for a very long time, but what you have to do is make the system look in the right path. So go the properties.cpp file in visual Studio and open the properties page (Thats what it is called in VS 2017). you'll find this page in the properties tab (on the right hand side) by clicking the wrench symbol. In there go to Configuration properties -> General -> Include search Path and add the path to the file that cannot be found, so in your case the properties.cpp file. Press apply and run again. hopefully it works. Im sorry all this refers to VS 2017 but the process should be the same probaply just different names.

[jflesch]

I'm seriously considering rewriting this library to make things simpler.

I'm thinking of a C library that would be built mostly using Mingw / Msys2 + GLib + GObject. The main advantages would be:

• I'm clearly more familiar with GNU tools than Microsoft ones.
• It would allow me to use GObject to provide bindings for theoretically any languages (Python, Java, C#, etc).
• I could then more easily use Msys2 to build Paperwork (and therefore use more recent versions of Python, GTK+, etc). Right now I can't ; python3 ./setup.py install in Msys2 can only fail, unless I build a wheel first with Visual C++.
• It would allow me to build most of the code with GCC only.

The drawbacks would be:

• I would still have to use Visual C++ for some basic parts (WIA linking and switching to pure C mostly). But I could easily provide prebuilt .dll/.h for those parts for those who don't want to bother compiling them.
• This library wouldn't be available simply through pip/pypi.

It would also be an opportunity for me to make a better API.