I would rather make a global module variable in the OpenCV files that a user can set to the path of their OpenCV 2.0 libs if they have more than one version installed. I see three situations: 1) a user wants to use scikits and doesnt have opencv - so they follow the build instructions and build 2.0 - no problems 2) a user wants to use scikits and has opencv 1.x - so they remove 1.x and build 2.0 - no problems 3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs. Cheers! Chris On Wed, Nov 4, 2009 at 4:28 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions"
This does look like the most painless way forward. Chris, would you mind putting up a big notice in the OpenCV docs?
A notice is good but does not really solve the issue right? If you need to have 1.x on your computer for whatever reason, you get crashes anyway when running the tests.
I like Holger's option b:
b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement.
Not sure if this works, but could you use multiprocess to import opencv and run a function known to fail in 1.x in a separate process. Then if it works, write something to a file, and read that file. If you avoid any shared objects this may work.
Alternatively, locate the opencv header somehow, and parse it.
Cheers, Ralf