[GEM-dev] [PD-dev] pix_opencv

[Antoine Villeret]

2012/12/13 Hans-Christoph Steiner <hans at at.or.at>:
>
> On Dec 13, 2012, at 3:43 AM, IOhannes m zmoelnig wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 2012-12-12 19:42, Antoine Villeret wrote:
>>> i've already tried to make a C++ external from the template but i
>>> never reach something which works so if you have a working template
>>> please let me know
>>
>> pix-opencv depends on external libraries, and afaik often needs
>> specific versions thereof.
>> i think it is a perfect candidate to *not* use a template Makefile but
>> instead use something more intelligent like autotools, scons,
>> cmake,...which reminds me that it already does use autoconf
>
>>> and what about including it in Gem ? as it depends on it (and it
>>> may depends on very new feature such as ROI soon) i think it's a
>>> better choice
>>
>> pix-opencv is developed by different people than Gem. i think it is
>> good to keep the repositories (and user-management) separate.
>> so: i'd rather not have pix-opencv be "part" of Gem.
>>
>> but:
>>
>> i agree that pix-opencv could be made more readily available to users.
>> it might be a good idea to distribute it together with Gem-releases.
>>
>> so:
>>
>> the build-system needs little changes to build a pix_opencv found in
>> extra/ (basically, uncomment the relevant lines at the end of
>> extra/configure.ac and add a line to extra/Makefile.am)
>>
>>
>>
>> we could then create a script that pulls in pix-opencv to
>> extra/pix_opencv before the builds are actually started.
>
> autotools are very useful for detecting platform differences and making the build system respond differently based on that, like handling multiple optional dependencies like in Gem.  For the case you describe, that works well with the template Makefile.  For an object that requires a specific library, add it to LDFLAGS.  If that library not installed, it'll throw an error, which is what you want since the object requires that library.  pix_opencv requires opencv, and does nothing without it, so no autotools necessary.

I don't know anything about autotool and it looks like quite dark for
me so if i can avoid another headache it's better :-)


>
> As for version differences, I generally find it way too much work to support building against various versions of the API and just choose one and standardize on it.  Then, once this lib is widely distributed it could be worth building against different versions of opencv if there is demand.  First get it out there for the majority of users, then deal with any relevant edge cases, otherwise you are likely to spend lots of time dealing with edge cases that might not really be relevant.
>
> My problem with autotools is that very few people know how to modify it, so the build system then rots because its not maintained and other issues.  I've seen this happen to a lot of autotools build systems in Pd projects over the years.  For example, Gem's autotools setup has gotten so complex, its almost impenetrable for me, and I've done a fair amount of autotools.  This is one reason to not include every object in Gem.
>
> The Makefile that's there is already quite close to working. I'm happy to commit fixes to get it working if that's OK with the maintainers.  I've committed to pix_opencv before.  Indeed I did this work back in 2009 but sevy objected so it was reverted and abandoned:
>
> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/pix_opencv/Makefile?r1=12563&r2=12571

I think we should ask Lluis for that
with the current Makefile in the SVN man should have opencv >= 2.3
(some externals won't compile with previous OpenCV version) but there
is not check about that I think
and I can build with
./configure --with-pd=<PATH> --with-gem=<PATH>
make

but only tested on Ubuntu
I don't know if it could build on other linux distro and even less on
Mac OS X and Windows
Should fixing that Makefile.in be a starting point to distrute the package ?

>
>> caveat:
>> both Gem and pix-opencv are complex projects. Gem has slow release
>> cycles, those of pix-opencv seems to be even more so.
>> synchronizing both projects so that we can create a "stable"
>> Gem-package including a "stable" pix-opencv could be impossible.
>>
>> so in a way it would be better if pix-opencv was distributed
>> separately, but actively.
>
>
> I agree, lumping everything into one giant package makes it into a maintenance headache and centralizes that headache on IOhannes, since he's the lead maintainer of Gem.  Its good to avoid it.

i do agree too, but I think it could be good to distribute pix_opencv
with Gem whenever it's possible and not too hurting for your head :-)

a.

>
> .hc
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev