OpenCV 2 or 1

[Chris Colbert]

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 at googlemail.com> wrote:
>
>
> 2009/11/4 Stéfan van der Walt <stefan at sun.ac.za>
>>
>> 2009/11/4 Chris Colbert <sccolbert at 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
>
>